Markus KARG created MNG-5332:
--------------------------------
Summary: Custom version scheme
Key: MNG-5332
URL: https://jira.codehaus.org/browse/MNG-5332
Project: Maven 2 & 3
Issue Type: New Feature
Components: POM
Affects Versions: 3.0.5
Reporter: Markus KARG
To be able to always find the latest bug fix (and for other use cases) Maven
supports version ranges. To be able to correctly detected whether a version is
in the range, or what the latest version of the detected version is, Maven has
to know the meaning of each part of the version. Maven currently is able to
deal with versions in the following syntax: Major.Minor.Build-Qualifier, where
Major, Minor and Build must be Integers, and Qualifier can be a String. Major,
Minor and Build will identify ascending post-GA versions, a qualifier always
will mark a version as pre-GA. So far, so good.
Unfortunatley, there are lots of other versioning syntaxes, like the rather
propular OSGi variant Major.Minor.Build.Qualifier where the Qualifier also is
found in POST-GA variants, and is separated by a dot.
As more and more OSGi artefacts are uploaded to Maven Central (like e. g. the
rather popular Hibernate suite), and as Maven users want to have such artefacts
as dependencies (while still using version ranges), the Maven range resolver
has to learn to deal with different version syntax.
My proposal is: Adding another POM element that teaches Maven what the patten
of a version is made of, and how to treat the qualifier. The idea is not yet
perfectly thought to the end, but shall trigger a discussion about a final
solution.
In the "foreign" (e. g. OSGi) artefact's POM, the following could be defined to
teach Maven (and all Maven related tools like Nexus) how to deal with
"non-mavenized" versions:
<version>4.5.6.Final</version>
<versionSyntax>[major(int,asc)].[minor(int,asc)].[build(int,asc)].[qualifier(resolve)]</versionSyntax>
<versionQualifierResolution>
<preGA>Alpha*, Beta*</preGA>
<postGA>SR*</postGA>
<GA>Final</GA>
</versionQualifierResolution>
This example defines the OSGi versioning scheme in a structured way so that
Maven will learn how to treat it: <version/> contains a version number in OSGi
syntax, so all artefacts will keep it (otherwise it won't work in OSGi
anymore). <versionSyntax> defines that the version is made up of four
dot-separated pieces. To make clear what is a piece and what is a literal,
pieces are [bracketed]. As Maven needs to find major, minor, build and
qualifier, these names are static and identify the position of that piece in
the pattern. "int" means "integer sorting rules". "str" means "string sorting
rules". "asc" and "desc" mean the sorting direction. "resolve" means that the
qualifier is not to be sorted, but to be resolved using the given table. In
that table, "pre" identifies the qualifiers that will mark the version number
as "pre GA" (= prior to the given version). Other possible values are "post GA"
(= past to the given version) and "GA" (= the qualifier does not further modify
the given version).
An alternative approach could be using reg ex instead of this new fancy syntax,
but then we have to define sorting and data type in a different way in the POM.
Please share your opinion! It is clear that OSGi enforces Maven to react in
some way. So here is my proposal. What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
