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
