-
1. Re: Maven Version ranges - The version format
alesj Mar 29, 2008 9:57 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
However Maven doesn't use that scheme:
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
instead it is
major.minor.micro-qualifier-build
So our
jboss-5.0.0.Beta4
should be under maven
jboss-5.0.0-Beta-4
for the version ranges to work properly.
Can't you hack this?
e.g. first trying how maven wants it, then also try our own
So that the old stuff would still work. -
2. Re: Maven Version ranges - The version format
adrian.brock Mar 29, 2008 10:24 AM (in response to adrian.brock)"alesj" wrote:
"adrian@jboss.org" wrote:
However Maven doesn't use that scheme:
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
instead it is
major.minor.micro-qualifier-build
So our
jboss-5.0.0.Beta4
should be under maven
jboss-5.0.0-Beta-4
for the version ranges to work properly.
Can't you hack this?
e.g. first trying how maven wants it, then also try our own
So that the old stuff would still work.
How? Something like<dependency> <groupId>org.jboss</groupId> <artifactId>jbossas</artifactId> <version format="OSGi">5.0.0.Beta4</version> </dependency>
With some config that tells maven how to parse versions into its format?<version-format name="OSGi">org.jboss.maven.OSGiVersionParser</version-format>
I'd guess it probably isn't as simple as that (but I haven't looked at the code. ;-) -
3. Re: Maven Version ranges - The version format
pmuir Mar 29, 2008 2:09 PM (in response to adrian.brock)+1
Even better IMO would be a way of specifying it is in OSGI mode for the whole POM. -
4. Re: Maven Version ranges - The version format
pmuir Mar 29, 2008 3:12 PM (in response to adrian.brock)So the language secret police tell me I'm not allowed to use an expression like "+1" here to show my support/gratitude for someones work.
Therefore, my post should read:
"Thanks Adrian, this investigation into Maven version ranges in general, and specifically into providing support for OSGi version ranges is really useful :-)"Even better IMO would be a way of specifying it is in OSGI mode for the whole POM.
Actually, this wouldn't work as you would probably have non jboss projects using the standard scheme.
But I don't think altering the maven schema like that will work - it would require a patched version of maven core afaik.
Perhaps a chained version parsing scheme? -
5. Re: Maven Version ranges - The version format
adrian.brock Mar 29, 2008 3:39 PM (in response to adrian.brock)"pete.muir@jboss.org" wrote:
So the language secret police tell me I'm not allowed to use an expression like "+1" here to show my support/gratitude for someones work.
It's not the language police, its the noise police. :-)
You only need to comment when you disagree or have something meaningful to add.
Everybody on these lists has a lot more interesting things to do with their time
than read endless copies of +1 e-mails. We don't vote on software at jboss.org
we do it by reasoned (sometimes colourful :-) argument, testing and JFDI. -
6. Re: Maven Version ranges - The version format
alesj Mar 29, 2008 3:46 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
"pete.muir@jboss.org" wrote:
So the language secret police tell me I'm not allowed to use an expression like "+1" here to show my support/gratitude for someones work.
It's not the language police, its the noise police. :-)
It's the Ales police. ;-) -
7. Re: Maven Version ranges - The version format
pgier Mar 31, 2008 11:54 AM (in response to adrian.brock)"alesj" wrote:
"adrian@jboss.org" wrote:
However Maven doesn't use that scheme:
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
instead it is
major.minor.micro-qualifier-build
So our
jboss-5.0.0.Beta4
should be under maven
jboss-5.0.0-Beta-4
for the version ranges to work properly.
Can't you hack this?
e.g. first trying how maven wants it, then also try our own
So that the old stuff would still work.
I was planning to bring up better support for the OSGi format on the maven dev list. Currently when maven tries to parse the last "." (instead of a "-") of our versions, it decides that we're using a non standard format and gives up on trying to parse it. If it seems worthwhile I can try to change the version number parsing so that it parses everything after the fourth dot as a qualifier or something like that to better handle OSGi.
I don't understand enough about how OSGi works, but as a second option, can we translate the maven version to something OSGi compatible in our builds? So maybe use the maven standard versions in our poms, but then put the equivalent OSGi version string into jar metadata, or somewhere else that it can be used? -
8. Re: Maven Version ranges - The version format
jason.greene Mar 31, 2008 1:39 PM (in response to adrian.brock)The maven version scheme is ugly, and unlike any convention I have seen. They should support custom versioning schemes, and provide an implementation for the common ones in use. I really am tired of having to change the way we do things just to make a build tool happy.
-
9. Re: Maven Version ranges - The version format
starksm64 Mar 31, 2008 4:30 PM (in response to adrian.brock)"pgier" wrote:
I don't understand enough about how OSGi works, but as a second option, can we translate the maven version to something OSGi compatible in our builds? So maybe use the maven standard versions in our poms, but then put the equivalent OSGi version string into jar metadata, or somewhere else that it can be used?
The osgi versioning convention is simply what we describe as ours here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning. Its just two short sections from the osgi r4 core spec:"osgi 4.0.1 core spec" wrote:
3.2.4 Version
Version specifications are used in several places. A version token has the following grammar:
version ::=
major( '.' minor ( '.' micro ( '.' qualifier )? )? )?
major ::= number
minor ::= number
micro ::= number
qualifier ::= ( alphanum | '_' | '-' )+
A version token must not contain any white space. The default value for a
version is 0.0.0.
3.2.5 Version Ranges
A version range describes a range of versions using a mathematical interval notation. See [31] Mathematical Convention for Interval Notation.
The syntax of a version range is:
version-range ::= interval | atleast
interval ::= ( '[' | '(' ) floor ',' ceiling ( ']' | ')' )
atleast ::= version
floor ::= version
ceiling ::= version
If a version range is specified as a single version, it must be interpreted as the range [version,infž). The default for a non-specified version range is 0, which maps to [0.0.0,infž).
Note that the use of a comma in the version range requires it to be enclosed in double quotes. For example:
Import-Package: com.acme.foo;version="[1.23, 2)", com.acme.bar;version="[4.0, 5.0)"
In the following table, for each specified range in the left-hand column, a
version x is considered to be a member of the range if the predicate in the
right-hand column is true.
Table 2 Examples of version ranges
Example Predicate
[1.2.3, 4.5.6) _____ 1.2.3 <= x < 4.5.6
[1.2.3, 4.5.6] _____ 1.2.3 <= x <= 4.5.6
(1.2.3, 4.5.6) _____ 1.2.3 < x < 4.5.6
(1.2.3, 4.5.6] _____ 1.2.3 < x <= 4.5.6
1.2.3 ____________ 1.2.3 <= x -
10. Re: Maven Version ranges - The version format
pgier Mar 31, 2008 5:02 PM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
The osgi versioning convention is simply what we describe as ours here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning. Its just two short sections from the osgi r4 core spec:
I understand the versioning from the spec, but I wasn't sure how these versions are actually used in the application when loading an OSGi component. Will we loose some compatibility if we use the maven standard for versions? Or can we put the OSGi compatible version string somewhere in our jars even though the pom has the maven compatible version? -
11. Re: Maven Version ranges - The version format
starksm64 Mar 31, 2008 5:31 PM (in response to adrian.brock)Ok, osgi has a separate Bundle-Version header for the bundle version information which would be needed. The java spec/implementation manifest headers would default to the maven version format still. Looking at the:
http://maven.apache.org/shared/maven-archiver/index.html#class_manifest
there is no way to transform the version other than specifying a new set of header values. It really comes down to needing a version policy so that there is only one pom.version specification that gets mapped to all of the version uses. -
12. Re: Maven Version ranges - The version format
heiko.braun Apr 3, 2008 4:39 AM (in response to adrian.brock)Another useful pick from "BetterBuildsWithMaven":
With regard to ordering, the elements are considered in sequence to determine which is newer - first
by major version, second - if the major versions were equal - by minor version, third by bug fix version,
fourth by qualifier (using string comparison), and finally, by build number. A version that contains a
qualifier is older than a version without a qualifier; for example, 1.2-beta is older than version 1.2. A
version that also contains a build number is considered newer than a version without a build number;
for example, 1.2-beta-1 is newer than 1.2-beta. In some cases, the versions will not match this syntax.
In those cases, the two versions are compared entirely as strings. -
13. Re: Maven Version ranges - The version format
heiko.braun Apr 3, 2008 4:41 AM (in response to adrian.brock)The more I get into it, the more I start thinking we should switch to the maven version format.
-
14. Re: Maven Version ranges - The version format
heiko.braun Apr 3, 2008 4:43 AM (in response to adrian.brock)I mean there is so much implicit behavior build into it, that can easily become a nightmare if we want to circumvent what's given.
But I think that's a general maven policy. It's the way it is.
If you want to do things differently, you get into trouble.