Need reviewers - 6856630: Restructure jaxp repository

Kelly O'Hair Kelly.Ohair at Sun.COM
Mon Aug 10 18:45:05 UTC 2009 

Andrew John Hughes wrote:
> 2009/8/10 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>
>> Andrew John Hughes wrote:
>>> 2009/8/8 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>> 2009/8/8 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>>>> Andrew John Hughes wrote:
>>>>>> 2009/8/8 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>>>>>> Yeah. I tossed this around in my head, drop seemed short and cute. ;^)
>>>>>>> Most if not all the import components are tools used to do the build
>>>>>>> but not sources that became part of the product built bits.
>>>>>>>
>>>>>>> Maybe the IcedTea guys can chime in on this.
>>>>>>>
>>>>>>> I'm happy to change it to another name that makes more sense.
>>>>>>>
>>>>>>> -kto
>>>>>>>
>>>>>>> Jonathan Gibbons wrote:
>>>>>>>> Well, elsewhere in the JDK build, the name "import" seems to cover
>>>>>>>> the
>>>>>>>> same concept
>>>>>>>> of inbound stuff from outside the repository.
>>>>>>>>
>>>>>>>> But, I know you do similar stuff in the FX world, so I wasn't sure if
>>>>>>>> "drop" came from there.
>>>>>>>>
>>>>>>>> -- Jon
>>>>>>>>
>>>>>>>> Kelly O'Hair wrote:
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> The drop name just dropped into my head :^)
>>>>>>>>>
>>>>>>>>> Do you have a better name for it?
>>>>>>>>>
>>>>>>>>> -kto
>>>>>>>>>
>>>>>>>>> Jonathan Gibbons wrote:
>>>>>>>>>> Is the "drop" name a standard convention, as compared to, say,
>>>>>>>>>> "import"?
>>>>>>>>>>
>>>>>>>>>> -- Jon
>>>>>>>>>>
>>>>>>>>>>
>>>>>> 'drop' sounds fine and makes sense to me at least.
>>>>>>
>>>>>> On more important matters, if I'm reading this right it does the
>>>>>> following as part of the build:
>>>>>>
>>>>>> #1: Finds a JAXP zip either via ALT_JAXP_SOURCE_BUNDLE or, failing
>>>>>> that, downloads one
>>>>>> #2: Extracts that bundle
>>>>>> #3: Builds the code
>>>>>>
>>>>> Yes, but actually if the drop area already exists, #1 and #2 are
>>>>> skipped.
>>>>> So if we bundle up a jdk source bundle and preload the drop/src in it,
>>>>> then that works too.
>>>>>
>>>>>> If that is the case, it sounds a hell of a lot like what IcedTea does
>>>>>> with OpenJDK anyway, so I can't see that much of a problem.  Is there
>>>>>> a bundle available so this can be tested?
>>>>>>
>>>>> Yes, this should work now. The copy will fail, then it should download
>>>>> a preliminary one we are testing with.
>>>>>
>>>> Great.  I'll try and have a quick look over the weekend and test it
>>>> with IcedTea.
>>>>
>>>>>> On the plus side, it would mean we weren't duplicating the JAXP and
>>>>>> JAXWS code about thirty times.
>>>>> Yup.
>>>>>
>>>>>> On the negative side, it makes it even less clear how changes get into
>>>>>> these.  We no doubt have some local ones already that would be lost by
>>>>>> using the bundle (though I think most are build changes to Makefiles
>>>>>> like DEBUG_CLASSFILES).  I don't think that's a blocker, but there
>>>>>> needs to be a clear documented route for getting patches into JAXP and
>>>>>> JAXWS just like we get them into the rest of OpenJDK.
>>>>> The JAXP changes would need to go through the JAXP team, I don't think
>>>>> that is a change, formal changes to these files always went through that
>>>>> team as far as I know.
>>>>> This should make it easier for the JAXP team to integrate their
>>>>> contribution into jdk7, so in theory we could get more frequent and
>>>>> newer JAXP sources.
>>>>>
>>>> Ok, I suppose what I meant is that the JAXP team is external to the
>>>> OpenJDK project as far as I'm aware.  While those of us external to
>>>> Sun are just about getting our heads round the processes and rights
>>>> involved in committing something here, I imagine it's a completely
>>>> different setup for JAXP.  Is there some resource that will point us
>>>> in the right direction for JAXP and JAXWS?
>>>>
>>>>> I did put a patch mechanism in place, for jdk7 emergencies.
>>>>> But I would think the first choice would always be to get a fresh
>>>>> drop bundle.
>>>>>
>>>>>> Any plans to do something similar with CORBA? :)
>>>>> Maybe... jaxp and jaxws first. corba is not part of the plan right now,
>>>>> but who knows...
>>>>>
>>>>> -kto
>>>>>
>>>>>
>>>> Thanks for this,
>>>> --
>>>> 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
>>>>
>>> No luck it seems...
>>>
>>>     [echo] Downloading from
>>> https://jaxp.dev.java.net/files/documents/913/140275/jdk7-jaxp-m5.zip
>>>      [get] Getting:
>>> https://jaxp.dev.java.net/files/documents/913/140275/jdk7-jaxp-m5.zip
>>>      [get] To: /mnt/builder/openjdk.icedtea/jaxp/drop_bundles/drop-src.zip
>>>      [get] Error getting
>>> https://jaxp.dev.java.net/files/documents/913/140275/jdk7-jaxp-m5.zip
>>> to /mnt/builder/openjdk.icedtea/jaxp/drop_bundles/drop-src.zip
>>>
>>> -drop-src-update:
>>>    [mkdir] Created dir: /mnt/builder/openjdk.icedtea/jaxp/drop/sources
>>>    [unzip] Expanding:
>>> /mnt/builder/openjdk.icedtea/jaxp/drop_bundles/drop-src.zip into
>>> /mnt/builder/openjdk.icedtea/jaxp/drop/sources
>>>
>>> BUILD FAILED
>>> /home/andrew/projects/openjdk/upstream/icedtea/jaxp/build.xml:187:
>>> Error while expanding
>>> /mnt/builder/openjdk.icedtea/jaxp/drop_bundles/drop-src.zip
>>> java.io.FileNotFoundException:
>>> /mnt/builder/openjdk.icedtea/jaxp/drop_bundles/drop-src.zip (No such
>>> file or directory)
>>>
>>> Built using my usual script:
>>>
>>> LANG=C make ALT_BOOTDIR=/usr/lib/icedtea6 \
>>>    ALT_OUTPUTDIR=/mnt/builder/openjdk.icedtea \
>>>    ALT_PARALLEL_COMPILE_JOBS=9 \
>>>    HOTSPOT_BUILD_JOBS=9 \
>>>    ALT_JIBX_LIBS_PATH=/home/andrew/projects/openjdk/jibx \
>>>    ANT=/usr/bin/ant
>> Try doing a 'ant clobber' then 'ant' again.
>>
>> I was able to download this file from my home network fine, but
>> java.net downloads are not horrible reliable, the bundle may be
>> truncated?  I suppose I should download to a temp file, then move
>> it to  the real file if there was no failure. I'll look at that.
>> This ant scripting is a bit bizarre. :^(
>>
>> -kto
>>
> 
> No luck, even wget seems to have stalled on it:
> 
> wget -v https://jaxp.dev.java.net/files/documents/913/140275/jdk7-jaxp-m5.zip
> --2009-08-10 04:04:25--
> https://jaxp.dev.java.net/files/documents/913/140275/jdk7-jaxp-m5.zip
> Resolving jaxp.dev.java.net... 204.16.104.198
> Connecting to jaxp.dev.java.net|204.16.104.198|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 5912912 (5.6M) [application/zip]
> Saving to: `jdk7-jaxp-m5.zip'
> 
> 29% [======================>
>                ] 1,736,704    489K/s  eta 11s

Can you try curl?:

    curl -o jdk7-jaxp-m5.zip https://jaxp.dev.java.net/files/documents/913/140275/jdk7-jaxp-m5.zip

If curl fails too, then it seems we have a server issue on java.net,
but why does it work for me and not you? :^(

FYI... The version of wget on my Mac is 1.11.4:

KellyMacBook.local<12> wget --version
GNU Wget 1.11.4

Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://www.gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic <hniksic at xemacs.org>.
Currently maintained by Micah Cowan <micah at cowan.name>.



-kto

More information about the build-dev mailing list