• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • maven-plugin
    • Jenkins 1.581
      Maven 3.0.5

      Hi,

      I'm currently facing an issue with the variable $POM_VERSION.
      I perform the following operations:

      1. Clean Workspace
      2. Checkout from Git (including the pom with Version 1.0.0)
      3. Execute Shell (or execute maven goal, both leads to the same result):
      mvn versions:set DnewVersion=${POM_VERSION}${BUILD_NUMBER};

      Now the POM-Version is set to e.g. 1.0.0-25.

      4. Publish 1.0.0-25 to Nexus

      So everything fine until now. I now Trigger the process the next time, but the variable $POM_VERSION still contains the value "1.0.0-25" from the last run, so the next artifact would be deployed as "1.0.0-25-26" and so on.

      I tried many things line unsetting the variables or copying them into other temp variables but I did not found a solution for this.

      Could you please check if POM_VERSION could be resetted at the beginning?

      Kind regards,

      Tobias

          [JENKINS-24869] POM_VERSION is not resetted

          Patrick Ryan added a comment -

          I noticed the POM variables are cached. After running Maven a couple of times I started using pre build scripts to do things with POM_GROUPID and others. After I updated some plugins and rebooted Jenkins, all the POM variables were gone. They don't return until you run some Maven target. (This is not very clear from the docs that make it should like the variables are always available.)

          Once I figured this out, I started running the "validate" goal first thing, which gives me all the variables right away, including POM_VERSION. However, if you update the version before committing, POM_VERSION doesn't reflect the new version. Validate shows the real version but my echo shows the old:

          [INFO] ------------------------------------------------------------------------
          [INFO] Building Pipeline Test 1.0.5-SNAPSHOT
          [INFO] ------------------------------------------------------------------------
          [INFO] 
          [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-requirements) @ pipeline_test ---
          [INFO] 
          [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-no-snapshots) @ pipeline_test ---
          [INFO] Skipping Rule Enforcement.
          [INFO] ------------------------------------------------------------------------
          [INFO] BUILD SUCCESS
          [INFO] ------------------------------------------------------------------------
          [INFO] Total time: 0.749 s
          [INFO] Finished at: 2015-08-20T08:35:27-07:00
          [INFO] Final Memory: 8M/452M
          [INFO] ------------------------------------------------------------------------
          [workspace] $ /bin/sh -xe /tmp/hudson247321079861255193.sh
          + echo 'VERSION: 1.0.4.45'
          VERSION: 1.0.4.45
          

          Later in my build, I run versions:set and install and deploy and it seems like one of those will update the cache so the next run will get the version from the last run. I'm always one run behind. I am trying to set the version number myself for continuous delivery but cannot rely on POM_VERSION.
          To get the version, I have been doing this (which is wasteful and ugly):

          `mvn org.apache.maven.plugins:maven-help-plugin:2.1.1:evaluate -Dexpression=project.version | grep -v "\[" |grep "\-SNAPSHOT"`
          

          Please update these variables whenever maven is invoked, never cache.
          Bonus: Make the variables available immediately, without needing to run maven first.

          Thanks

          Patrick Ryan added a comment - I noticed the POM variables are cached. After running Maven a couple of times I started using pre build scripts to do things with POM_GROUPID and others. After I updated some plugins and rebooted Jenkins, all the POM variables were gone. They don't return until you run some Maven target. (This is not very clear from the docs that make it should like the variables are always available.) Once I figured this out, I started running the "validate" goal first thing, which gives me all the variables right away, including POM_VERSION. However, if you update the version before committing, POM_VERSION doesn't reflect the new version. Validate shows the real version but my echo shows the old: [INFO] ------------------------------------------------------------------------ [INFO] Building Pipeline Test 1.0.5-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-requirements) @ pipeline_test --- [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-no-snapshots) @ pipeline_test --- [INFO] Skipping Rule Enforcement. [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.749 s [INFO] Finished at: 2015-08-20T08:35:27-07:00 [INFO] Final Memory: 8M/452M [INFO] ------------------------------------------------------------------------ [workspace] $ /bin/sh -xe /tmp/hudson247321079861255193.sh + echo 'VERSION: 1.0.4.45' VERSION: 1.0.4.45 Later in my build, I run versions:set and install and deploy and it seems like one of those will update the cache so the next run will get the version from the last run. I'm always one run behind. I am trying to set the version number myself for continuous delivery but cannot rely on POM_VERSION. To get the version, I have been doing this (which is wasteful and ugly): `mvn org.apache.maven.plugins:maven-help-plugin:2.1.1:evaluate -Dexpression=project.version | grep -v "\[" |grep "\-SNAPSHOT" ` Please update these variables whenever maven is invoked, never cache. Bonus: Make the variables available immediately, without needing to run maven first. Thanks

          Patrick Ryan added a comment - - edited

          To reproduce:
          restart jenkins
          pull from git (example: version=1.0.0-SNAPSHOT)
          echo ${POM_VERSION} (will probably be blank)
          invoke maven->validate
          echo ${POM_VERSION} (will be 1.0.0-SNAPSHOT)

          update version in repo and push (example: 1.0.1-SNAPSHOT)
          pull from git
          echo ${POM_VERSION} (will still be 1.0.0-SNAPSHOT, cached)
          invoke maven->validate
          echo ${POM_VERSION} (will still be 1.0.0-SNAPSHOT, not updated from maven invoke)

          My versions:
          Jenkins: 1.610
          Maven Integration Plugin: 2.10
          There is also -
          Maven Release Plug-in Plug-in: 0.14.0
          installed (i'm not using, but there are a lot of users on our jenkins, I hope this isn't interfering in anyway)

          Patrick Ryan added a comment - - edited To reproduce: restart jenkins pull from git (example: version=1.0.0-SNAPSHOT) echo ${POM_VERSION} (will probably be blank) invoke maven->validate echo ${POM_VERSION} (will be 1.0.0-SNAPSHOT) update version in repo and push (example: 1.0.1-SNAPSHOT) pull from git echo ${POM_VERSION} (will still be 1.0.0-SNAPSHOT, cached) invoke maven->validate echo ${POM_VERSION} (will still be 1.0.0-SNAPSHOT, not updated from maven invoke) My versions: Jenkins: 1.610 Maven Integration Plugin: 2.10 There is also - Maven Release Plug-in Plug-in: 0.14.0 installed (i'm not using, but there are a lot of users on our jenkins, I hope this isn't interfering in anyway)

          Marc Carter added a comment -

          I think this should be bumped up from Minor. It's increasingly common to avoid maven-release-plugin for CD and use versions and scm plugins directly. $POM_VERSION makes a big difference to the effectiveness of such strategies.

          My own usecase is simply that I want to do release:perform -DreleaseVersion=$BUILD_NUMBER -DdevelopmentVersion=$POM_VERSION to reset it back to whatever it was before.

          http://stackoverflow.com/questions/25532555/jenkins-pom-version-variable-does-not-reset-from-build-to-build
          http://stackoverflow.com/questions/9893503/getting-maven-version-in-jenkins
          http://sofb.developer-works.com/article/19313014/Jenkins+Maven+POM+Version+number+not+changing

          Marc Carter added a comment - I think this should be bumped up from Minor. It's increasingly common to avoid maven-release-plugin for CD and use versions and scm plugins directly. $POM_VERSION makes a big difference to the effectiveness of such strategies. My own usecase is simply that I want to do release:perform -DreleaseVersion=$BUILD_NUMBER -DdevelopmentVersion=$POM_VERSION to reset it back to whatever it was before. http://stackoverflow.com/questions/25532555/jenkins-pom-version-variable-does-not-reset-from-build-to-build http://stackoverflow.com/questions/9893503/getting-maven-version-in-jenkins http://sofb.developer-works.com/article/19313014/Jenkins+Maven+POM+Version+number+not+changing

          Any updates or plans of release for this ticket?

          Diego Marinelli added a comment - Any updates or plans of release for this ticket?

          Also seeing this issue trying to drive versioning for CD via jenkins in Jenkins 1.609.3

          Scott MacDonald added a comment - Also seeing this issue trying to drive versioning for CD via jenkins in Jenkins 1.609.3

          Zahir Toufie added a comment - - edited

          Experiencing the problem with a similar usecase to Marc Carter. I'm using Jenkins 1.646.

          I've resorted to adding a shell script to all my build tasks that require the POM_VERSION field;

          POM_VERSION=`mvn help:evaluate -Dexpression=project.version | sed -n -e '/^\[.*\]/ !{ /^[0-9]/ { p; q } }'`
          

          This bug, get's my vote.

          Zahir Toufie added a comment - - edited Experiencing the problem with a similar usecase to Marc Carter. I'm using Jenkins 1.646. I've resorted to adding a shell script to all my build tasks that require the POM_VERSION field; POM_VERSION=`mvn help:evaluate -Dexpression=project.version | sed -n -e '/^\[.*\]/ !{ /^[0-9]/ { p; q } }' ` This bug, get's my vote.

          Andy Costanza added a comment -

          same problem on Jenkins 2.3...

          Andy Costanza added a comment - same problem on Jenkins 2.3...

          rherrick added a comment - - edited

          I'm still getting this issue on Jenkins v2.51 with Maven integration plugin v2.15.1. This makes the integration plugin almost useless. I'm trying to tie the RELEASE_VERSION setting to the Maven version property (pretty reasonable) and imagine my surprise when the new release has the last version.

          It looks to me like the problem is that it's setting the POM properties before pulling from VCS. I re-ran my release build and this time got the updated version.

          rherrick added a comment - - edited I'm still getting this issue on Jenkins v2.51 with Maven integration plugin v2.15.1. This makes the integration plugin almost useless. I'm trying to tie the RELEASE_VERSION setting to the Maven version property (pretty reasonable) and imagine my surprise when the new release has the last version. It looks to me like the problem is that it's setting the POM properties  before pulling from VCS. I re-ran my release build and this time got the updated version.

          mors crucio added a comment -

          Still happens the 2.32.1.

          We also see that, when trying to run 2 job on the same build, one with each version, the $POM_VERSION is incorrect in one of them

          mors crucio added a comment - Still happens the 2.32.1. We also see that, when trying to run 2 job on the same build, one with each version, the $POM_VERSION is incorrect in one of them

          Luís Cleto added a comment -

          Also affecting me. $POM_VERSION is not correct if 2 jobs run using the same build and happen to have different versions.

          Luís Cleto added a comment - Also affecting me. $POM_VERSION is not correct if 2 jobs run using the same build and happen to have different versions.

            Unassigned Unassigned
            tobias_schaber tobias schaber
            Votes:
            28 Vote for this issue
            Watchers:
            31 Start watching this issue

              Created:
              Updated: