Re: Repository version precedence

[John Sisson <jr...@gmail.com>]

Thanks Ian,

I registered for it yesterday, but am still waiting to receive the email 
with the download link.  Hoping it will fill in some holes in the 
documentation.

John

ian.d.stewart@jpmchase.com wrote:
> John,
>
> Did you include "Better Builds with Maven" in your documentation search?
> If not, you can download the book here:
>
> http://www.mergere.com/m2book_download.jsp
>
> I haven't looked into it myself, but from what I understand it covers alot
> about Maven that was previously only captured within e-mail threads.
>
>
> Ian
>
> It's better to be hated for who you are
> than loved for who you are not
>
> Ian D. Stewart
> Appl Dev Analyst-Advisory, DCS Automation
> JPMorganChase Global Technology Infrastructure
> Phone: (614) 244-2564
> Pager: (888) 260-0078
>
>
>                                                                            
>              John Sisson                                                   
>              <jrsisson@gmail.c                                             
>              om>                                                        To 
>                                        dev@geronimo.apache.org             
>              05/30/2006 11:47                                           cc 
>              PM                                                            
>                                                                    Subject 
>                                        Re: Repository version precedence   
>              Please respond to                                             
>              dev@geronimo.apac                                             
>                   he.org                                                   
>                                                                            
>                                                                            
>                                                                            
>
>
>
>
> Joe Bohn wrote:
>   
>> Am I the only one concerned about this?
>>
>>     
> I am also concerned, just been a bit busy to respond. See comments
> inline below.
>
>   
>> I think this is an important issue for our users.  They won't have the
>> luxury to wait for a completely new Geronimo image to fix a problem
>> with an embedded component.  They will also face these issues with
>> their own versioned application modules.  I would appreciate your input.
>>
>> Thanks,
>> Joe
>>
>>
>> Joe Bohn wrote:
>>     
>>> I'm trying to get my head around the way that we make a version
>>> selection when multiple versions of a package are available.   This
>>> will be important as users need to include different versions of
>>> packages beyond what geronimo bundles or if they need to override a
>>> package with a local version.
>>>
>>>       
> I agree with David Jencks that we should use the same rules as Maven and
> work with the Maven project if there is something we need from Maven
> that it doesn't currently provide.
>
> There isn't much official documentation on the maven site regarding
> version handing. Most of the documentation related to versioning I have
> found on mailing lists and confluence:
>
> * http://marc.theaimsgroup.com/?t=113633603700001&r=1&w=2 " - indicates
> that version support in maven may be enhanced in Maven 2.1.
> *
> http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies
> ( also accessible from the the "Extending Maven 2.0 Dependencies" link
> on http://docs.codehaus.org/display/MAVEN/Maven+2.1+Design+Documents .
> *
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
>
> * http://marc.theaimsgroup.com/?t=113144703400002&r=1&w=2
>
>   
>>> I was working with the tomcat jars and so I was looking for ways to
>>> drop in a modified version of the jars and have them picked up
>>> without removing the 5.5.15 versions.   Here are the items that I
>>> tried and which was chosen when compared to 5.5.15
>>>
>>> 1) 5.5.15.1
>>> -  Apparently any version with more than 2 dots is considered invalid
>>> and so the entire version is considered to be a qualifier (with a
>>> null for the major, minor incrementalVersion, and build - basically
>>> treated as 0.0.0-"5.5.15.1"). Any valid version is considered newer.
>>> -  5.5.15 is chosen over 5.5.15.1
>>> -  5.5.10 is chosen over 5.5.15.1
>>>       
> Hmm, I noticed we already have dependency JARs with four numbers in it
> (more than 2 dots) such as the Derby JARs , e.g. 10.1.1.0 .  I wonder
> how many JARs out there could have four or more numbers considering the
> maven documentation does not currently mention any restriction.
>
>   
>>> 2) 5.5.15-1
>>> -  The "-" is used to specify a qualifier or buildnumber.  Since the
>>> value after the dash was numeric, it was considered to be a
>>> buildnumber.  It appears that a build number is always considered
>>> newer than a package without a buildnumber.
>>> -  5.5.15-1 is chosen over 5.5.15
>>>
>>> 3) 5.5.15-01
>>> -  The code (Version.java) treats the leading "0" as a special case.
>>> This makes the last part a qualifier rather than a build number.  Any
>>> qualified version is considered to be lower than a non-qualified
>>> version (such as with -SNAPSHOT).  Anybody know why this special
>>> check for "0" is in there?
>>> -  5.5.15 is chosen over 5.5.15-01
>>>       
> AFAIK, the version code was taken from Maven, so might be worth asking
> the Maven project.
>   
>>> 4) 5.5.15-alpha
>>> -  If the portion following the "-" starts with an alphabetic
>>> character then this last portion is considered a qualifier.  Once
>>> again, the qualified release is considered older than the same
>>> version non-qualified.
>>> -  5.5.15 is chosen over 5.5.15-alpha
>>>
>>>
>>> First, we need to document this behavior very clearly for users that
>>> need to replace packages we ship (or their own packages included in
>>> the repo).
>>>
>>> Second, I would like to propose some changes:
>>> -  IMO a qualified release should generally be considered *newer*
>>> than a non-qualified release.  I think SNAPSHOT would be the only
>>> exception. Right now we treat that exception as the rule for all
>>> qualifiers. I think we should add specific code for "SNAPSHOT" and
>>> have all other qualified releases take precedence over a
>>> non-qualified release.  I can imagine users wanting to add
>>> myjar-1.1-patch1.jar to replace myjar-1.1.jar.
>>> -  I think we should treat a third "." to be the logical equivalent
>>> of a "-" in the version.  Most users would expect 5.5.15.1 to be
>>> major version 5, minor version 5, incremental version 15,
>>> build/rev/patch/whatever 1 and consider this to be newer than 5.5.15.
>>> See #1 above for how we really treat 3 dots.  Providing 5.5.15-1
>>> gives substantially different results than providing 5.5.15.1 which
>>> is not intuitive.
>>>
>>>       
> See comment above regarding Derby's versioning. Need to discuss any
> enhancements with Maven project to ensure we remain compatible.
>   
>>> Joe
>>>
>>>
>>>       
>
>
>
>
>