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
