2009/10/28 Andrew John Hughes <gnu_and...@member.fsf.org>: > 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. > -- > 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 >
That's with IcedTea6 1.6.1. The same happens with my build of OpenJDK6 from earlier today. The drops.dir issue was obviously because the tarball has changed, so shows that it catches such a change. -- 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
