geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Geronimo Specs 1.1-SNAPSHOT
Date Mon, 30 Jan 2006 01:26:57 GMT

On Jan 29, 2006, at 4:45 PM, David Blevins wrote:

>
> On Jan 29, 2006, at 3:13 PM, David Jencks wrote:
>
>>
>> On Jan 29, 2006, at 2:35 PM, David Blevins wrote:
>>
>>> On Jan 29, 2006, at 2:01 PM, David Jencks wrote:
>>>
>>>>
>>>> On Jan 29, 2006, at 1:41 PM, David Blevins wrote:
>>>>
>>>>> On Jan 28, 2006, at 11:51 AM, David Jencks wrote:
>>>>>
>>>>>> On Jan 28, 2006, at 10:57 AM, Alan D. Cabrera wrote:
>>>>>>
>>>>>>> I've updated the trunk of Geronimo Specs to 1.1-SNAPSHOT.   
>>>>>>> The thinking is that we update the versions of all the spec 

>>>>>>> jars in tandem.  The rational for that is that end developers
 
>>>>>>> will not want to pick and choose what got updated in our  
>>>>>>> collection of spec jars but, instead, will just want the  
>>>>>>> latest and greatest version for the entire set.
>>>>>>>
>>>>>>>
>>>>>> IMO a more important reason is that we are aggregating all the  
>>>>>> specs into an uber-spec-jar that contains everything.  In  
>>>>>> order for this jar to have a meaningful version all the things  
>>>>>> of which it is built have to have the same version.  In any  
>>>>>> case, I certainly agree this is the right thing to do.
>>>>>>
>>>>>
>>>>> I see and understand those points, but I would like to add the  
>>>>> points that:
>>>>>
>>>>>  1. issuing new versions of jars that don't change creates a  
>>>>> confusing mess in public repos and classpaths.
>>>>>  2. snapshots and new jars off all the specs is a terrible way  
>>>>> to deal with one or two edge cases of jars that change.
>>>>>
>>>>> But as opinions are cheap, I figured I'd actually revaluate  
>>>>> where we are at in concrete terms.  I grabbed all the source  
>>>>> from 2 years ago, 10 months ago (near passing the cts), and now  
>>>>> then stripped out all the comments and diff'ed them.  Here is  
>>>>> what I found.
>>>>>
>>>>> no code changes in 2 years:
>>>>>  - ejb
>>>>>  - j2ee-connector
>>>>>  - j2ee-deployment
>>>>>  - j2ee-management
>>>>>  - jms
>>>>>  - jsp
>>>>>  - jta
>>>>>  - servlet
>>>>>
>>>>> no code changes in 10 months:
>>>>>  - activation
>>>>>  - jaxr
>>>>>  - qname (new)
>>>>>  - saaj (new)
>>>>>  - jaxrpc (new)
>>>>>
>>>>> These two seem to have changed the most:
>>>>>  - j2ee-jacc (no change since M5)
>>>>>  - javamail (problem child)
>>>>>
>>>>>
>>>>> IMHO, doesn't make sense to keep pushing new versions into the  
>>>>> public for stuff that doesn't change.
>>>>>
>>>>> What do others think?
>>>>
>>>> You left out the corba spec module, whose changes precipitated  
>>>> the current brouhaha.
>>>>
>>>> I'm fine with either:
>>>>
>>>> 1. dropping the uber-spec-jar entirely
>>>> 2. keeping versions of every spec jar in sync.
>>>>
>>>> I might be willing to consider another alternative if someone  
>>>> would explain what it was, and how the uber-spec-jar version  
>>>> would be determined after each of these individual events, each  
>>>> of which requires re-releasing the uber-spec-jar:
>>>>
>>>> individual spec jar A changes to say 1.1
>>>> individual spec jar B changes to say 1.1
>>>> individual spec jar A changes to say 1.2
>>>>
>>>> So far I haven't seen any actual other proposals to (1) or (2)
>>>>
>>>
>>> I think we should just push new version of a spec jar at an  
>>> appropriate time when said jar changes.  For the uber-spec jar we  
>>> can just push a new version when a dep spec jar changes.
>>>
>>> Seem reasonable?
>>
>> To me this is not a proposal until you specify what the uber spec  
>> jar revision is after each of the changes I mentioned.  An  
>> algorithm would be even better :-)
>>
>> So, not yet :-)
>>
>
> Sure.  Everything has it's own version number which will be  
> incremented by one.

so you are thinking
>>>>> individual spec jar A changes to say 1.1  >> uber version 1.1 :
 
>>>>> contains mix of 1.0 and 1.1 versioned jars
>>>>> individual spec jar B changes to say 1.1  >> uber version 1.2 :
 
>>>>> still contains mix of 1.0 and 1.1 versioned jars
>>>>> individual spec jar A changes to say 1.2  >> uber version 1.3 :
 
>>>>> contains mix of 1.0, 1.1, and 1.2 versioned jars

?

To me this has the disadvantage that you have no way whatsoever of  
telling what is in the uber spec jar from its version or contents  
without binary comparisons.  I consider this a fatal objection or at  
least much more of a problem than incrementing the versions for all  
jars simultaneously even though most have not changed.

So, I'm trying to add a requirement that the casual user be able to  
figure out which jars went into each uber-jar we release from the  
uber-jar itself.

thanks
david jencks

>
> -David
>
>


Mime
View raw message