1 2 Previous Next 16 Replies Latest reply on Apr 17, 2008 10:51 AM by Paul Gier

    Maven Version ranges - The version format

    Adrian Brock Master

      I'm in the process of testing Maven's version constraint handling.
      I'm going to use different threads to document each issue found

      First the version format:

      The way we are specifying versions is similar to how OSGi handles versions
      i.e. major.minor.micro.qualifier

      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.

        • 1. Re: Maven Version ranges - The version format
          Ales Justin Master

           

          "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 Master

             

            "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
              Pete Muir Master

              +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
                Pete Muir Master

                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 Master

                   

                  "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
                    Ales Justin Master

                     

                    "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
                      Paul Gier Master

                       

                      "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 Master

                        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
                          Scott Stark Master

                           

                          "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
                            Paul Gier Master

                             

                            "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
                              Scott Stark Master

                              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 Master

                                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 Master

                                  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 Master

                                    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.

                                    1 2 Previous Next