You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2006/05/26 22:42:51 UTC
Repository version precedence
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
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.
- 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.
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
Re: Repository version precedence
Posted by Joe Bohn <jo...@earthlink.net>.
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
Re: Repository version precedence
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Having consistency is definitely in ours and Maven's best interest. We (us and the Maven guys) need
to examine how people manage their versions. Derby is clearly a case where 4 elements is standard.
I also agree with David that more dots isn't necessarily good but I've also noticed on the user
list that people like jars with and without version numbers. The point is that there are a number
of standards that are not necessarily consistent.
More inline...
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.
Being consistent is good. However, Geronimo is a separate project and I think we need to also be
defensive as well. IMHO that means consistency is good but remembering that users of Geronimo could
probably care less about our build tool. Notes on the user list seem to indicate the users see our
adoption of Maven paradigms confusing and of no additional value to them.
> I certainly think that we need very clear documentation on what the
> version numbers mean.
Yup
> 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
I think the above is confusing. I would expect this to be a component that is modeled on 5.5.16 +
something else. I think something like:
5.5.15-*patch*n...n implies we started with 5.5.15 and this jar is that + something. Using a
specific suffix like PATCH and some number would eliminate and ambiguity. I think if Maven defined
that naming convention that would help us all.
> 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
Yup...I prefer PATCH; the question is does this imply a whole replacement for the component. I
would think that is easiest but thought we should clarify.
> 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
>
>
>
>
Re: Repository version precedence
Posted by David Jencks <da...@yahoo.com>.
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
Re: Repository version precedence
Posted by 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
>>>
>>>
>>>
>
>
>
>
>
Re: Repository version precedence
Posted by ia...@jpmchase.com.
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
>>
>>
>
Re: Repository version precedence
Posted by John Sisson <jr...@gmail.com>.
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
>>
>>
>
Re: Repository version precedence
Posted by Joe Bohn <jo...@earthlink.net>.
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
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
>
> 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.
> - 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.
>
> 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