<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Andrew John Hughes wrote:
<blockquote
cite="mid:17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com"
type="cite">
<pre wrap="">2009/10/28 Andrew John Hughes <a class="moz-txt-link-rfc2396E" href="mailto:gnu_andrew@member.fsf.org"><gnu_andrew@member.fsf.org></a>:
</pre>
<blockquote type="cite">
<pre wrap="">2009/10/28 Kelly O'Hair <a class="moz-txt-link-rfc2396E" href="mailto:Kelly.Ohair@sun.com"><Kelly.Ohair@sun.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">
Joseph D. Darcy wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Andrew John Hughes wrote:
</pre>
<blockquote type="cite">
<pre wrap="">2009/10/23 Kelly O'Hair <a class="moz-txt-link-rfc2396E" href="mailto:Kelly.Ohair@sun.com"><Kelly.Ohair@sun.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Jonathan Gibbons wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Kelly O'Hair wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Jonathan Gibbons wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Kelly O'Hair wrote:
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">[big snip]
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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. ;^)
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">-kto
</pre>
<blockquote type="cite">
<pre wrap="">-Joe
</pre>
</blockquote>
</blockquote>
<pre wrap="">
--
Andrew :-)
Free Java Software Engineer
Red Hat, Inc. (<a class="moz-txt-link-freetext" href="http://www.redhat.com">http://www.redhat.com</a>)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
<a class="moz-txt-link-freetext" href="http://www.gnu.org/software/classpath">http://www.gnu.org/software/classpath</a>
<a class="moz-txt-link-freetext" href="http://openjdk.java.net">http://openjdk.java.net</a>
PGP Key: 94EFD9D8 (<a class="moz-txt-link-freetext" href="http://subkeys.pgp.net">http://subkeys.pgp.net</a>)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
</pre>
</blockquote>
<pre wrap=""><!---->
I was just testing a webrev for the ALT_DROPS_DIR change on tl and hit this:
-jaxp_src-url-bundle:
[echo] Downloading from
<a class="moz-txt-link-freetext" href="https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip">https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip</a>
[mkdir] Created dir: /mnt/builder/tl/jaxp/drop/bundles
[get] Getting:
<a class="moz-txt-link-freetext" href="https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip">https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip</a>
[get] To: /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp
[get] Error getting
<a class="moz-txt-link-freetext" href="https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip">https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip</a>
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.
</pre>
</blockquote>
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.<br>
<br>
-- Jon<br>
</body>
</html>