2009/10/28 Andrew John Hughes <gnu_and...@member.fsf.org>: > 2009/10/28 Kelly O'Hair <kelly.oh...@sun.com>: >> >> >> Andrew John Hughes wrote: >>> >>> 2009/10/28 Jonathan Gibbons <jonathan.gibb...@sun.com>: >>>> >>>> Andrew John Hughes wrote: >>>> >>>> 2009/10/28 Andrew John Hughes <gnu_and...@member.fsf.org>: >>>> >>>> >>>> 2009/10/28 Kelly O'Hair <kelly.oh...@sun.com>: >>>> >>>> >>>> Joseph D. Darcy wrote: >>>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>> 2009/10/23 Kelly O'Hair <kelly.oh...@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 :-) 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
