Need reviewers - 6856630: Restructure jaxp repository

[Andrew John Hughes]

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