[jira] (MNG-5332) Custom version scheme

["Markus KARG (JIRA)" <ji...@codehaus.org>]

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