geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Organization and versioning of specs; a new proposal
Date Wed, 16 Aug 2006 22:21:09 GMT
I guess I'd still prefer we do <artifactId>-<version> for the tag  
names as maven does.

There's also a small catch in that the directories we've been using  
are not the artifactIds.

-David

On Aug 16, 2006, at 2:06 PM, Jason Dillon wrote:

> Does not really look like anything needs to be moved.  The only  
> things (other than svn ci) would be svn mkdir for each spec in  
> tags, since mvn release will not make that tree... as in:
>
> <snip>
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-activation
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-commonj
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-corba
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-corba-2.3
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-corba-3.0
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-j2ee
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-j2ee-connector
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-j2ee-deployment
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-j2ee-jacc
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-j2ee-management
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-javamail-1.3.1
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-javamail-1.4
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-jaxr
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-jaxrpc
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-jms
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-jsp
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-jta
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-qname
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-saaj
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-servlet-2.4
> svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/ 
> geronimo-spec-servlet-2.5
> </snip>
>
> I think everything else is just pom updates.
>
> --jason
>
>
> On Aug 16, 2006, at 1:50 PM, David Jencks wrote:
>
>>
>> On Aug 16, 2006, at 1:40 PM, Jason Dillon wrote:
>>
>>> I have always been in favor of dropping any uber-jars.  They  
>>> cause more problems then they are worth.
>>>
>>> As for RTC... I am not so sure that this applies really.  Its not  
>>> going to surprise anyone, its not adding any new code... just  
>>> fixing up the poms and moving a few bits around in svn.
>>>
>>> But, I can jump though the RTC hoop if that is what the PMC  
>>> wants... I think its a waste of time... mostly mine.
>>
>> This is obviously not something that a patch will work for in  
>> terms of comprehension and probably function.
>>
>> If we need RTC I think that supplying the svn mv commands is what  
>> we'd vote on.
>>
>> I think we have voted on the desired outcome and that is  
>> sufficient, but I won't push the issue.
>>
>> Jason, how hard would it be to come up with the svn commands you'd  
>> use, and what else is there to do?
>>
>> thanks
>> david jencks
>>
>>>
>>> --jason
>>>
>>>
>>> On Aug 16, 2006, at 7:13 AM, Kevan Miller wrote:
>>>
>>>>
>>>> On Aug 16, 2006, at 3:56 AM, Jason Dillon wrote:
>>>>
>>>>> What is the status on 1.1.1 wrt this change?  Can I go ahead  
>>>>> and make these changes?
>>>>
>>>> My reading of Matt's note (which I agree with) is that you  
>>>> should wait until 1.1.1 has been shipped (unless 1.1.1 runs into  
>>>> an extended delay in releasing due to administrative matters).
>>>>
>>>> I think this change should follow the RTC process. This is not a  
>>>> bug fix, not a doc change, etc. It's updating svn and changing  
>>>> the way we deliver specs -- my read is that it falls under RTC.
>>>>
>>>> You don't mention geronimo-j2ee_1.4_spec (the uber-jar). It's  
>>>> currently versioned using the top-level pom version. I assume  
>>>> you plan on adding a geronimoSpecsJ2eeVersion?
>>>>
>>>> Your process for updating the jms spec would be:
>>>>
>>>>     cd specs/geronimo-spec-jms
>>>>     mvn release
>>>>     cd ../geronimo-spec-j2ee
>>>>     mvn release
>>>>
>>>> I'm not so sure that this is any better than we have now... I  
>>>> see two options:
>>>>
>>>> 1) drop the uber-jar
>>>> 2) release all specs simultaneosly (even if they haven't  
>>>> changed) and all have the same version...
>>>>
>>>> --kevan
>>>>
>>>>>
>>>>> --jason
>>>>>
>>>>>
>>>>> On Aug 12, 2006, at 12:16 AM, Matt Hogstrom wrote:
>>>>>
>>>>>> Jason,
>>>>>>
>>>>>> I'm +1 on the change.  In order to release 1.1.1 we need to  
>>>>>> release an updated version of the J2EE_JAAC specs.  I am  
>>>>>> waiting for feedback from Geir on some licensing issues as  
>>>>>> well as a TCK run that Kevan is doing.  That said I'd prefer  
>>>>>> to wait until the we cut the 1.1.1 release.  If it looks like  
>>>>>> its going to be delayed due to the licensing concerns then we  
>>>>>> should do this straight away next week.
>>>>>>
>>>>>> Since this isn't a code change I agree with Jason's comments  
>>>>>> on no review required.  Lazy consensus is appropriate here.
>>>>>>
>>>>>> Jason Dillon wrote:
>>>>>>> A while ago there was talks about independently versioning  
>>>>>>> specs, and Alan started a reorg branch which gives each spec
 
>>>>>>> module its own trunk+branches+tags...
>>>>>>> I have been thinking about this for a while, and with the  
>>>>>>> recent desire to split off more modules from geronimo/trunk 

>>>>>>> I've been pondering it even more.  What I have come to  
>>>>>>> believe is that spitting up spec modules into their own trunk

>>>>>>> +branches+tags is probably not the best direction for us to 

>>>>>>> head in.
>>>>>>> I believe that all of our specs can, and should, share one  
>>>>>>> trunk... and still have each module specify its own version.
  
>>>>>>> This is very similar to how Maven2 plugins is setup, see here:
>>>>>>>     http://svn.apache.org/repos/asf/maven/plugins
>>>>>>> Each plugin has its own version that changes independently. 
 
>>>>>>> The top-level pom has a version too, which is independent and
 
>>>>>>> is only changed when there is a major configuration change in
 
>>>>>>> that pom.
>>>>>>> I recommend that we follow this model for our specs.
>>>>>>> The advantage to one trunk, is that it facilitates easy check
 
>>>>>>> out and building when you just want all of the specs.  If  
>>>>>>> each spec was in its own trunk, you would need to svn co each
 
>>>>>>> one, then mvn install in each tree, which is a pain.
>>>>>>> We also almost never branch specs, they just keep chugging  
>>>>>>> along, only really needing tags to track released versions.
>>>>>>> So, here is what I propose:
>>>>>>>     specs/trunk/pom.xml
>>>>>>>     specs/trunk/<artifactId>
>>>>>>>     specs/tags/<artifactId>/<version>
>>>>>>> And if needed:
>>>>>>>     specs/branches/<artifactId>/<name>
>>>>>>> This is a single trunk so to build all specs:
>>>>>>>     svn co https://svn.apache.org/repos/asf/geronimo/specs/ 
>>>>>>> trunk/ specs
>>>>>>>     cd specs
>>>>>>>     mvn install
>>>>>>> To release an individual spec, say geronimo-spec-jms:
>>>>>>>     cd specs/geronimo-spec-jms
>>>>>>>     mvn release
>>>>>>> The m2 release plugin can be configured with a _tag base_,  
>>>>>>> which we can set to:
>>>>>>>     https://svn.apache.org/repos/asf/geronimo/specs/tags/$ 
>>>>>>> {pom.artifactId}
>>>>>>> When released, the plugin will svn cp just the module's  
>>>>>>> directory into a directory under tags, so it will be easy to
 
>>>>>>> see what the released versions of a specific spec are.
>>>>>>>  * * *
>>>>>>> I really do not see the need for each spec to have its own  
>>>>>>> trunk, and really I think that if we did then it would just 

>>>>>>> make it more difficult for cases when we really want all specs.
>>>>>>> I do not see any downside to the approach above.
>>>>>>> I recommend that we implement this.  The only major change, 

>>>>>>> which isn't that major, is that the properties which live in
 
>>>>>>> the root pom that control the versions need to be removed...
 
>>>>>>> or rather moved back to the <version> element of the  
>>>>>>> respective pom.
>>>>>>> Comments?
>>>>>>> --jason
>>>>>
>>>>
>>>
>>
>


Mime
View raw message