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
