Uploaded image for project: 'Maven'
  1. Maven
  2. MNG-5576

Allow continuous delivery friendly versions

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.1
    • Fix Version/s: 3.2.1
    • Component/s: None
    • Labels:
      None

      Description

      Currently warnings will be emitted when there are expressions in versions, a few exceptions should be deemed valid to make continuous delivery easier. The use case is to allow easy versioning of an entire multi-module build that can take a version from an external source like SCM. These are the types of exceptions that will be allowed:

      1.0.0.${changelist}
      1.0.0.${revision}
      1.0.0.${sha1}

      When a whole build is versioned like this we can avoid churning the POMs in the SCM which makes it a lot easier to see the actual changes in the project. Not a complete solution for continuous delivery but is a step in the right direction and doesn't interfere with currently behavior as it is currently allowed, just warned against.

        Issue Links

          Activity

          Hide
          jvanzyl Jason van Zyl added a comment - - edited
          Show
          jvanzyl Jason van Zyl added a comment - - edited Implemented on 88d0abcd30a0ab040850b3086b3f0ddd8e9607f3
          Hide
          domi Dominik Richner added a comment -

          Please point users to some valid documentation on how to use this feature and how it relates/works with the maven-release-plugin.

          Show
          domi Dominik Richner added a comment - Please point users to some valid documentation on how to use this feature and how it relates/works with the maven-release-plugin.
          Hide
          jvanzyl Jason van Zyl added a comment -

          There is nothing to use per se, it just prevents the warning when using the $

          {changelist}

          , $

          {revision}

          , and $

          {sha1}

          in the version. It is not specifically related to the maven-release-plugin. This is not directly related to the maven-release-plugin as the maven-release-plugin cannot be used for continuous delivery because it requires rebuilding.

          Show
          jvanzyl Jason van Zyl added a comment - There is nothing to use per se, it just prevents the warning when using the $ {changelist} , $ {revision} , and $ {sha1} in the version. It is not specifically related to the maven-release-plugin. This is not directly related to the maven-release-plugin as the maven-release-plugin cannot be used for continuous delivery because it requires rebuilding.
          Hide
          mfriedenhagen Mirko Friedenhagen added a comment -

          I "abuse" the preparationGoals parameter of release:prepare and get away we a one shot invocation, see https://github.com/1and1/foss-parent/blob/master/release for an example.

          Show
          mfriedenhagen Mirko Friedenhagen added a comment - I "abuse" the preparationGoals parameter of release:prepare and get away we a one shot invocation, see https://github.com/1and1/foss-parent/blob/master/release for an example.
          Hide
          jvanzyl Jason van Zyl added a comment -

          I mean more that once you have built it there is no rebuild. More akin to having used a snapshot and then turned it into a release artifact. Essentially you build a stream of binaries and then select one based on its merit. At that point you don't rebuild it. This is not really how Maven currently works.

          Show
          jvanzyl Jason van Zyl added a comment - I mean more that once you have built it there is no rebuild. More akin to having used a snapshot and then turned it into a release artifact. Essentially you build a stream of binaries and then select one based on its merit. At that point you don't rebuild it. This is not really how Maven currently works.
          Hide
          vmassol Vincent Massol added a comment - - edited

          Hi. Why not support any property in <parent>/<version> elements in POM or if that's not possible, why not support {{$

          {project.version}}}?

          I'd like to be able to to write:
          
          

          ...
          <parent>
          <groupId>org.xwiki.platform</groupId>
          <artifactId>xwiki-platform-activeinstalls</artifactId>
          <version>${project.version}

          </version>
          </parent>
          ...

          
          And in the top level POM have:
          
          

          ...
          <version>1.0-SNAPSHOT</version>
          ...

          
          

          Thanks

          Show
          vmassol Vincent Massol added a comment - - edited Hi. Why not support any property in <parent>/<version> elements in POM or if that's not possible, why not support {{$ {project.version}}}? I'd like to be able to to write: ... <parent> <groupId>org.xwiki.platform</groupId> <artifactId>xwiki-platform-activeinstalls</artifactId> <version>${project.version} </version> </parent> ... And in the top level POM have: ... <version>1.0-SNAPSHOT</version> ... Thanks
          Hide
          khmarbaise Karl Heinz Marbaise added a comment -

          First why using an old issue instead of creating a new one and not discuss this on the dev list?...furthermore if you use ${project.version} from where should it be taken? Apart from that you can use a revision, sha1 or changelist etc. in the parent and you can use -Drevision=xxxxx on command line etc. I would suggest to remove you comment and create either a new issue (feature request) or better start a discussion on the dev list?

          Show
          khmarbaise Karl Heinz Marbaise added a comment - First why using an old issue instead of creating a new one and not discuss this on the dev list?...furthermore if you use ${project.version } from where should it be taken? Apart from that you can use a revision , sha1 or changelist etc. in the parent and you can use -Drevision=xxxxx on command line etc. I would suggest to remove you comment and create either a new issue (feature request) or better start a discussion on the dev list?
          Hide
          vmassol Vincent Massol added a comment - - edited

          furthermore if you use project.version from where should it be taken?

          From the resolved project's version.

          What I don't understand and my comment is for this issue, not another one (otherwise I'd have created it elsewhere...), is why the restriction on revision, sha1 and changelist property names.

          Re the list I'm not subscribed to the list (not been for years now) and I don't intend to join it. This was just a one-off question related to a specific jira issue.

          Show
          vmassol Vincent Massol added a comment - - edited furthermore if you use project.version from where should it be taken? From the resolved project's version. What I don't understand and my comment is for this issue, not another one (otherwise I'd have created it elsewhere...), is why the restriction on revision , sha1 and changelist property names. Re the list I'm not subscribed to the list (not been for years now) and I don't intend to join it. This was just a one-off question related to a specific jira issue.
          Hide
          khmarbaise Karl Heinz Marbaise added a comment -

          You wrote from resolved project's where should it be defined ? There must be at least one location where it's need to be defined. So if you take a multi module build you can define it once in the root of that multi module build. In the child modules it might be implemented to accept project.version. So currently the revision, sha1 and changelist is at the moment defined which means they are allowed to prevent emitting of warnings during the build and using special properties which can be defined from command line of from .mvn/maven.confg file...but this concepts can of course being improved so you just omit the project.version completely. My assumption about the implementation is simply to use properties instead doing much more complicated things..(For this you might better ask Jason van Zyl).

          Show
          khmarbaise Karl Heinz Marbaise added a comment - You wrote from resolved project's where should it be defined ? There must be at least one location where it's need to be defined. So if you take a multi module build you can define it once in the root of that multi module build. In the child modules it might be implemented to accept project.version . So currently the revision , sha1 and changelist is at the moment defined which means they are allowed to prevent emitting of warnings during the build and using special properties which can be defined from command line of from .mvn/maven.confg file...but this concepts can of course being improved so you just omit the project.version completely. My assumption about the implementation is simply to use properties instead doing much more complicated things..(For this you might better ask Jason van Zyl).
          Hide
          vmassol Vincent Massol added a comment -

          The way it could be done:

          • If you're in a multi module project and the parent can be found in the filesystem, then resolve project.version by traversing the parent hierarchy upward till you find a pom.xml containing a <version> element.
          • If you're in a single module and/or the parent is not found on the filesystem (nor in .mvn/maven.config), and the current pom.xml doesn't define a <version> element then emit an error that project.version is undefined and maybe allow users to pass it on the command line (not even sure that it's needed).

          Note that omimtting completely omit the <version> in the <parent> element would normally resolve it to the latest released version which may not be what we want.

          Thanks for your answers. When i read the release notes for 3.2.1 I was happy initially to see the ability to support some variables for parent versions. After looking at it, I was disappointed that it was only working for some edge cases and I was wondering if there was a technical reason.

          Keep the good of making Maven progress! (which I dropped years ago on my side to dedicate my time to xwiki).

          Show
          vmassol Vincent Massol added a comment - The way it could be done: If you're in a multi module project and the parent can be found in the filesystem, then resolve project.version by traversing the parent hierarchy upward till you find a pom.xml containing a <version> element. If you're in a single module and/or the parent is not found on the filesystem (nor in .mvn/maven.config ), and the current pom.xml doesn't define a <version> element then emit an error that project.version is undefined and maybe allow users to pass it on the command line (not even sure that it's needed). Note that omimtting completely omit the <version> in the <parent> element would normally resolve it to the latest released version which may not be what we want. Thanks for your answers. When i read the release notes for 3.2.1 I was happy initially to see the ability to support some variables for parent versions. After looking at it, I was disappointed that it was only working for some edge cases and I was wondering if there was a technical reason. Keep the good of making Maven progress! (which I dropped years ago on my side to dedicate my time to xwiki).

            People

            • Assignee:
              Unassigned
              Reporter:
              jvanzyl Jason van Zyl
            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development