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
