6856630: Restructure jaxp/jaxws repository

Wed Oct 28 18:45:55 UTC 2009

Andrew John Hughes wrote:
> 2009/10/28 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>   
>> 2009/10/28 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>     
>>> Joseph D. Darcy wrote:
>>>       
>>>> Andrew John Hughes wrote:
>>>>         
>>>>> 2009/10/23 Kelly O'Hair <Kelly.Ohair at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20091028/d4bfea72/attachment.htm>