2009/8/8 Andrew John Hughes <gnu_and...@member.fsf.org>:
> 2009/8/8 Kelly O'Hair <kelly.oh...@sun.com>:
>>
>>
>> Andrew John Hughes wrote:
>>>
>>> 2009/8/8 Kelly O'Hair <kelly.oh...@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
--
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
