geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Geronimo specs pre-RTC
Date Mon, 03 Jul 2006 23:54:24 GMT
Jason Dillon wrote:
> I think it is more work than it is worth to try and create patches and 
> have separate issues for this.
Patches don't work for moving dirs, IIUC.
>
>  * * *
>
> This will generally move individual modules from 
> http://svn.apache.org/repos/asf/geronimo/specs/trunk/XXX to 
> http://svn.apache.org/repos/asf/geronimo/specs/XXX/trunk and then 
> clean up the pom's  right?
Yep.
>
> I think it is still a good idea to have them all extend from a parent 
> pom... there is still stuff that would be good to centralize, but the 
> parent and the child do not need to exists within the same tree and do 
> not need to share the same version.
I see no reason for there to be a parent POM.  What stuff needs to be 
centralized?  Can you explain what the phrase "the parent and the child 
do not need to exists within the same tree and do not need to share the 
same version" means?
> I recommend creating a top-level spec-config/trunk/pom.xml that has 
> all of the common pom configuration... then release it a 1.0, and have 
> each of the spec pom's extend from that.  Spec config will almost 
> never change (unless we have to change project urls or repos)... but 
> when we do, its easier to manage in a central place.
The whole point of this change is to get *rid* of the root POM.
> I think we eventually need a general project-config module that we can 
> share with all sub-projects.  That module would be part of a 
> build-support project where our independent custom modules and build 
> configuration lives.
Why?


Regards,
Alan
>
> --jason
>
>
> On Jul 3, 2006, at 3:54 PM, Alan D. Cabrera wrote:
>
>> We had talked about breaking out the Geronimo specs so that they 
>> don't share the same root pom.   There seemed to be a consensus that 
>> this was a good idea.  John Sisson mentioned that we might need 
>> separate Jiras for each.  I think that that might be excessive given 
>> how the specs jars are unlikely to change.
>>
>> The nature of this change is that it will not be possible to make a 
>> patch to reflect the changes that need to be done.  What I can do is 
>> to concretely express the changes that need to be made in an RTC.  
>> Thoughts?
>>
>>
>> Regards,
>> Alan
>>
>>
>


Mime
View raw message