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>: > > > 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, > > Some of the comments in the Makefiles need to be updated -- for example, > references to devtools in lines 89, 100 > > -- Jon >
Well spotted; revised version here: http://cr.openjdk.java.net/~andrew/drops/webrev.03/ -- 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
