Need reviewers - 6856630: Restructure jaxp repository

[Kelly O'Hair]

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