geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ian.d.stew...@jpmchase.com
Subject Re: Repository version precedence
Date Wed, 31 May 2006 13:24:26 GMT
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
>>
>>
>




Mime
View raw message