geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: Repository version precedence
Date Wed, 31 May 2006 02:56:10 GMT
David,

I understand your point about potential confusion if we extend the maven 
capabilities.  However, I have to wonder how many of our users are 
familiar with maven and if this is important to them.

If we are to stay closely aligned with Maven, then I agree with you that 
need to pursue some of these items with maven.  It could be that we are 
using maven in a context other than it's original intent and therefore 
we are hitting some usability issues that they normally not consider 
important. I like your idea of a special qualifier that is considered 
more recent (such as PRIVATE).

Is our current logic in Version.java completely consistent with maven 
today?  I might not be looking in the right place, but I haven't seen 
maven document ion stating that a version with 3 dots or more would be 
treated as a qualifier alone (basically assuming a 0.0.0 release).  I 
also didn't see any mention of the special case treatment of a 
buildnumber starting with "-0" to be considered a qualifier rather than 
a build number (there was a reference to appending a -0 to a version for 
comparison purposes if a match was not found and no qualifier was 
specified).  I'm basing most of my maven understanding on this 
description: 
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution


Joe

David Jencks wrote:
> 
> On May 30, 2006, at 10:49 AM, Joe Bohn wrote:
> 
>> Am I the only one concerned about this?
>>
>> 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
>>
> 
> Overall I think we need to keep consistent with maven on this.   Having 
> slightly different rules for geronimo compared to maven will  create 
> more confusion that any advantage we might gain.  There's also  some 
> desire to actually use the maven classes to work with  repositories and 
> artifacts, which would make it even more likely that  we follow maven 
> conventions.
> 
> I certainly think that we need very clear documentation on what the  
> version numbers mean.
> 
> I think we might be able to work with maven to come up with some  
> additional possibilities.  I think that our basic use case that maven  
> may not support too well is producing a private build of an artifact  
> that is already released from an outside project.  Currently the only  
> ways to do this are by incrementing a build number (which can  conflict 
> with an official later release) or by incrementing the  incremental 
> version and including a qualifier: so
> 5.5.15
> 
> gets replaced by
> 
> 
> 5.5.16-MyPrivateBuild
> 
> which will in turn be replaced by any official 5.5.16 release from  the 
> project.
> 
> I'm not sure what problems this last might cause.
> 
> Perhaps we could lobby maven for a special qualifier keyword that is  
> after all build numbers?  e.g. 5.5.15-PRIVATE-23455
> 
> A couple more comments inlne
> 
> thanks
> david jencks
> 
>>
>> 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 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
> 
> 
> I'm not sure more dots are a good thing.
> 
>>> 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
>>> 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.
> 
> 
> A lot of people use -DEV which is definitely before a plain build  
> number.  I don't think moving most qualifiers to after build numbers  
> will fly: I think a special keyword for this might.
> 
>>> -  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.
> 
> 
> I don't think these definitely need to have the same meaning.  I  think 
> that allowing 3 dots means we should allow any number of  dots.... and  
> I'm not sure we really need the resultant complexity.
> 
> 
>>> Joe
>>
>>
>> -- 
>> Joe Bohn
>> joe.bohn at earthlink.net
>>
>> "He is no fool who gives what he cannot keep, to gain what he  cannot 
>> lose."   -- Jim Elliot
> 
> 
> 
> 

-- 
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Mime
View raw message