[
https://jira.codehaus.org/browse/MNG-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5332:
--------------------------------
Affects Version/s: (was: 3.1.x)
3.2.x
> Custom version scheme
> ---------------------
>
> Key: MNG-5332
> URL: https://jira.codehaus.org/browse/MNG-5332
> Project: Maven
> Issue Type: New Feature
> Components: POM
> Affects Versions: 3.2.x
> 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 was sent by Atlassian JIRA
(v6.1.6#6162)
