6856630: Restructure jaxp/jaxws repository
Jonathan Gibbons
Jonathan.Gibbons at Sun.COM
Wed Oct 28 21:39:22 UTC 2009
Andrew John Hughes wrote:
> 2009/10/28 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>
>> 2009/10/28 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>
>>> Andrew John Hughes wrote:
>>>
>>>> 2009/10/28 Jonathan Gibbons <Jonathan.Gibbons at sun.com>:
>>>>
>>>>> Andrew John Hughes wrote:
>>>>>
>>>>> 2009/10/28 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>>>
>>>>>
>>>>> 2009/10/28 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>>>>
>>>>>
>>>>> Joseph D. Darcy wrote:
>>>>>
>>>>>
>>>>> Andrew John Hughes wrote:
>>>>>
>>>>>
>>>>> 2009/10/23 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>>>>
>>>>>
>>>>>
>>>>> Jonathan Gibbons wrote:
>>>>>
>>>>>
>>>>>
>>>>> Kelly O'Hair wrote:
>>>>>
>>>>>
>>>>>
>>>>> Jonathan Gibbons wrote:
>>>>>
>>>>>
>>>>>
>>>>> Kelly O'Hair wrote:
>>>>>
>>>>>
>>>>>
>>>>> [big snip]
>>>>>
>>>>>
>>>>> DOH! Sorry...
>>>>>
>>>>> Yes, these jaxp and jaxws forests can probably go away, we won't
>>>>> be using them.
>>>>>
>>>>> The current plan is that jaxp/jaxws changes (new bundles) will go
>>>>> through the TL forest.
>>>>>
>>>>>
>>>>> -kto
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I'm guilty of also thinking that Jonathan was referring to the jaxws
>>>>> and jaxp repositories per forest, rather than the specific forests.
>>>>> On that note, i18n could probably die too because apparently that team
>>>>> always use the swing forest for commits.
>>>>>
>>>>> It would be nice to one day get rid of the jaxp and jaxws trees too.
>>>>> I don't actually see why they were created as trees to begin with,
>>>>> given they've always been upstream and not a source of many commits.
>>>>> The one to actual split up would be jdk, as I can feel Mercurial
>>>>> struggling with it a bit already on jdk7. But I don't know how
>>>>> feasible that is, if at all. Maybe Jigsaw will help there.
>>>>>
>>>>> One thing that does worry me -- what happens when the jaxws or jaxp
>>>>> code needs security updates?
>>>>>
>>>>>
>>>>>
>>>>> Yes, the need to support security fixes was considered as part of this
>>>>> new
>>>>> delivery model. Ultimately a revised source bundle with the security
>>>>> fixes
>>>>> will need to be produced. Until then, the fixes can be represented as
>>>>> patches which are applied to the sources before the build. Kelly can
>>>>> speak
>>>>> to the implementation details of the patch mechanism.
>>>>>
>>>>>
>>>>> It's crude, but should serve in an emergency. See the patches/README.
>>>>> After a bundle is unzipped, all patches are applied, none right now.
>>>>>
>>>>> I hope that we can always just get updated bundles.
>>>>>
>>>>> Originally, the jaxp and jaxws (and corba) workspaces were created
>>>>> mainly as a place to move files from (trim) the original "j2se"
>>>>> workspace,
>>>>> and we had no idea where we were going with it all, except that we
>>>>> knew these were out of place in the j2se workspace, which became
>>>>> the jdk repository.
>>>>>
>>>>> The jaxp and jaxws repos could just go away someday, but I'll leave
>>>>> that for another day. ;^)
>>>>>
>>>>> Let's just call it evolution. ;^)
>>>>>
>>>>>
>>>>>
>>>>> Oh yes, I'm not saying right now -- something for JDK8 perhaps? :)
>>>>> Certainly, the trivial change Jonathan mentions could be done when
>>>>> creating the jdk8 forests.
>>>>> It would be nice to share the common stuff between jaxp and jaxws too,
>>>>> and I suspect that may be easier if they are in the same toplevel
>>>>> openjdk repository.
>>>>>
>>>>>
>>>>>
>>>>> -kto
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -Joe
>>>>>
>>>>>
>>>>> --
>>>>> Andrew :-)
>>>>>
>>>>> Free Java Software Engineer
>>>>> Red Hat, Inc. (http://www.redhat.com)
>>>>>
>>>>> Support Free Java!
>>>>> Contribute to GNU Classpath and the OpenJDK
>>>>> http://www.gnu.org/software/classpath
>>>>> http://openjdk.java.net
>>>>>
>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>>>>>
>>>>>
>>>>>
>>>>> I was just testing a webrev for the ALT_DROPS_DIR change on tl and hit
>>>>> this:
>>>>>
>>>>> -jaxp_src-url-bundle:
>>>>> [echo] Downloading from
>>>>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip
>>>>> [mkdir] Created dir: /mnt/builder/tl/jaxp/drop/bundles
>>>>> [get] Getting:
>>>>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip
>>>>> [get] To: /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp
>>>>> [get] Error getting
>>>>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip
>>>>> to /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp
>>>>>
>>>>> BUILD FAILED
>>>>> javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected
>>>>> error: java.security.InvalidAlgorithmParameterException: the
>>>>> trustAnchors parameter must be non-empty
>>>>> at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
>>>>> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1627)
>>>>> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1590)
>>>>> at
>>>>> sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1573)
>>>>> at
>>>>> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1166)
>>>>> at
>>>>> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1143)
>>>>> at
>>>>> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423)
>>>>> at
>>>>>
>>>>> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
>>>>> at
>>>>>
>>>>> sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
>>>>> at org.apache.tools.ant.taskdefs.Get.doGet(Get.java:145)
>>>>> at org.apache.tools.ant.taskdefs.Get.execute(Get.java:78)
>>>>> at
>>>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
>>>>> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>>>>> at
>>>>>
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>> at java.lang.reflect.Method.invoke(Method.java:616)
>>>>> at
>>>>>
>>>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>>>>> at org.apache.tools.ant.Task.perform(Task.java:348)
>>>>> at org.apache.tools.ant.Target.execute(Target.java:357)
>>>>> at org.apache.tools.ant.Target.performTasks(Target.java:385)
>>>>> at
>>>>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
>>>>> at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
>>>>> at
>>>>>
>>>>> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
>>>>> at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
>>>>> at org.apache.tools.ant.Main.runBuild(Main.java:758)
>>>>> at org.apache.tools.ant.Main.startAnt(Main.java:217)
>>>>> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
>>>>> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
>>>>>
>>>>> Firstly, I obviously have to wonder why it's still downloading, but
>>>>> this seems to be caused by the new URL.
>>>>>
>>>>>
>>>>> I'm curious: is there an option to prevent downloading the source bundle?
>>>>> It seems to me that if you think you've set up the build to not need to
>>>>> download anything, it would be nice if the build failed if the bits were
>>>>> not
>>>>> available, rather than have it try and find the bits. Automatic
>>>>> downloads
>>>>> sound bad, IMO.
>>>>>
>>>>> -- Jon
>>>>>
>>>>>
>>>> It would be a nice additional option, I don't think it already exists.
>>>> At present, it happens accidentally in that the JDK crashes
>>>> instead... :(
>>>>
>>>> This is interesting:
>>>>
>>>> /mnt/builder/tl/jaxws/build/xml_generated/build-drop-jaxws_src.xml:117:
>>>> Checksum on file
>>>> /mnt/builder/tl/jaxws/drop/bundles/jdk7-jaxws-2009_09_28.zip is
>>>> debb949440c5a15ce999cfefbbc56526, not
>>>> f5010ebf636db9f465a61a7a74944543
>>>>
>>>> Did the jaxws bundle change without being renamed?
>>>>
>>> I certainly hope not.
>>>
>>> These are the md5 sums I have on all the bundles:
>>>
>>> bonsai<11> /usr/bin/sum -x md5 /java/devtools/share/jdk*drops/*.zip
>>> 7a50bb540a27cdd0001885630088b758
>>> /java/devtools/share/jdk6-drops/jdk6-jaf-2009_10_27.zip
>>> 0bb03bbd7b1b6d87cc65772c6adb2d6a
>>> /java/devtools/share/jdk6-drops/jdk6-jaxp-2009_10_27.zip
>>> 3ea5728706169498b722b898a1008acf
>>> /java/devtools/share/jdk6-drops/jdk6-jaxws-2009_10_27.zip
>>> eb8cb7a4a7f14e211fbe2354878a2472
>>> /java/devtools/share/jdk7-drops/jdk7-jaf-2009_08_28.zip
>>> d99f4777bc4c42d7759f7c0fcf87ef5d
>>> /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_08_28.zip
>>> 8800970d03bab1fff188dcfafc346f5d
>>> /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_09_28.zip
>>> 8b58ce7919cda8e32a9afc5cb4b58bb1
>>> /java/devtools/share/jdk7-drops/jdk7-jaxp-m5.zip
>>> debb949440c5a15ce999cfefbbc56526
>>> /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_08_28.zip
>>> f5010ebf636db9f465a61a7a74944543
>>> /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_09_28.zip
>>>
>>> -kto
>>>
>>>
>> Ok it appears I have 08_28 masquerading as 09_28. Thanks.
>> --
>> Andrew :-)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>>
>>
>
> Ok here's the webrev for the ALT_DROPS_DIR change against tl:
>
> http://cr.openjdk.java.net/~andrew/drops/webrev.02/
>
> Ok to push? Do we have a bug ID for this?
>
> Thanks,
>
Andrew,
Some of the comments in the Makefiles need to be updated -- for example,
references to devtools in lines 89, 100
-- Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20091028/ddb52cbf/attachment.htm>
More information about the build-dev
mailing list