Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-8651

Maven deployment with uniqueVersion == true creating "new" versions for attached artifacts

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • maven-plugin
    • None
    • Hudson 1.395

      When using uniqueVersion == true with Maven deployments for artifacts that have attached artifacts (specifically hpi artifacts in this case...) I've observed the following behavior:

      • MavenArtifactRecord.deploy for pom and main artifact (hpi) occurs as expected, assigning unique version in sequence (i.e. "-5")
      • When MavenArtifactRecord.deploy reaches the iteration for .attachedArtifacts (line #128) and begins deploying these the unique version will be incremented (i.e. "-6")
        • I've confirmed that when the artifact is "transformed" by the SnapshotTransformer, specifically line #104, that an incorrect "nextBuildNumber" is determined. This is due to #resolveLatestSnapshotBuildNumber (line 151) returning the "current" build number.

      This seems to be a regression for 1.395 as the same setup worked fine in 1.383

          [JENKINS-8651] Maven deployment with uniqueVersion == true creating "new" versions for attached artifacts

          Jason Stiefel added a comment -

          @Olamy-

          Thanks for looking into it. Very frustrating problem for me right now. I have confirmed that the same behavior is exhibited when I overload MavenArtifactRecord.deployArtifact to use the "default" Maven Deployer rather than the "maven2" implementation you added back in December.

          The upside to switching to the built-in artifact deployer was that I can finally use the httpclient wagon provider for uploads, which was a really nice find while debugging the original issue of incrementing snapshot versions

          As a bit more detail here's what I'm seeing uploaded into Nexus for a single build:

          mygroup:myartifact:1.8-SNAPSHOT,2343434-1:pom
          mygroup:myartifact:1.8-SNAPSHOT,2343434-1:hpi
          mygroup:myartifact:1.8-SNAPSHOT,2343435-2:jar <- Where this is the "attached" artifact on the build.

          I had thought earlier that the timestamps were identical but noticed later on that might have been a fluke and the timestamp will fluctuate a bit between the pom+main and attached artifacts. In the maven-metadata.xml I see 3 artifacts listed, each with different extension elements: pom, hpi and jar. Only the jar shows as build #2 and that's also listed as the "current build". So when I go to grab the latest snapshot of the hpi artifact- it's not found as there is no hpi artifact in build #2, just the jar.

          Please let me know if I can provide additional detail. I'm even happy to submit a patch if you have a suggestion on where I should "fix" this!

          Jason Stiefel added a comment - @Olamy- Thanks for looking into it. Very frustrating problem for me right now. I have confirmed that the same behavior is exhibited when I overload MavenArtifactRecord.deployArtifact to use the "default" Maven Deployer rather than the "maven2" implementation you added back in December. The upside to switching to the built-in artifact deployer was that I can finally use the httpclient wagon provider for uploads, which was a really nice find while debugging the original issue of incrementing snapshot versions As a bit more detail here's what I'm seeing uploaded into Nexus for a single build: mygroup:myartifact:1.8-SNAPSHOT,2343434-1:pom mygroup:myartifact:1.8-SNAPSHOT,2343434-1:hpi mygroup:myartifact:1.8-SNAPSHOT,2343435-2:jar <- Where this is the "attached" artifact on the build. I had thought earlier that the timestamps were identical but noticed later on that might have been a fluke and the timestamp will fluctuate a bit between the pom+main and attached artifacts. In the maven-metadata.xml I see 3 artifacts listed, each with different extension elements: pom, hpi and jar. Only the jar shows as build #2 and that's also listed as the "current build". So when I go to grab the latest snapshot of the hpi artifact- it's not found as there is no hpi artifact in build #2, just the jar. Please let me know if I can provide additional detail. I'm even happy to submit a patch if you have a suggestion on where I should "fix" this!

          Jason Stiefel added a comment -

          Olamy-

          I've solved this in the interim by creating my own artifact promoter using Aether. If you would be interested in looking at my solution please let me know.

          Jason Stiefel added a comment - Olamy- I've solved this in the interim by creating my own artifact promoter using Aether. If you would be interested in looking at my solution please let me know.

          Olivier Lamy added a comment -

          Nice do you have time to provide a patch ?
          Thanks !

          Olivier Lamy added a comment - Nice do you have time to provide a patch ? Thanks !

          Jason Stiefel added a comment -

          Well it's less a matter of time and more a question of how you'd like to approach a final solution. My implementation is intended to be extensible (eventually support non-maven artifacts) and also compatible with the Promoted Builds plugin. Here's the breakdown-

          • Recorder implementation that converts MavenArtifactRecords into an intermediate dto that implements my "Promotable" interface. Once converted (or wrapped really) into Promotable it delegates to:
          • A "Promoter" (AetherPromoter in this case) that is constructed from (credentials, localRepository, remoteRepositories[]). The promoter then uses Aether to upload the artifacts. My implementation uses the artifact version to determine whether it should aim for the snapshots or releases repositories, but then I'm building towards a more integrated target where my Nexus instance is actually deployed as part of the overall CI server (this approach removes the "repository url" configuration from the job entirely- the repo locations are known. however I could see value in being able to define the repo releases and snapshots repos at both a global level and optionally override at a job level...)

          This process may be a little too specific for the core maven-plugin, or it may be just what the core needs as a start towards using Aether and Maven repositories in general for arbitrary binary artifact storage. Your call, share your thoughts and I'll see how quickly I can "generalize" this and to what extent.

          Jason Stiefel added a comment - Well it's less a matter of time and more a question of how you'd like to approach a final solution. My implementation is intended to be extensible (eventually support non-maven artifacts) and also compatible with the Promoted Builds plugin. Here's the breakdown- Recorder implementation that converts MavenArtifactRecords into an intermediate dto that implements my "Promotable" interface. Once converted (or wrapped really) into Promotable it delegates to: A "Promoter" (AetherPromoter in this case) that is constructed from (credentials, localRepository, remoteRepositories[]). The promoter then uses Aether to upload the artifacts. My implementation uses the artifact version to determine whether it should aim for the snapshots or releases repositories, but then I'm building towards a more integrated target where my Nexus instance is actually deployed as part of the overall CI server (this approach removes the "repository url" configuration from the job entirely- the repo locations are known. however I could see value in being able to define the repo releases and snapshots repos at both a global level and optionally override at a job level...) This process may be a little too specific for the core maven-plugin, or it may be just what the core needs as a start towards using Aether and Maven repositories in general for arbitrary binary artifact storage. Your call, share your thoughts and I'll see how quickly I can "generalize" this and to what extent.

          Olivier Lamy added a comment -

          fixed in more simple way.
          Will be in 1.398

          Olivier Lamy added a comment - fixed in more simple way. Will be in 1.398

          Code changed in jenkins
          User: Olivier Lamy
          Path:
          maven-plugin/pom.xml
          maven-plugin/src/main/java/hudson/maven/reporters/MavenArtifact.java
          maven-plugin/src/main/java/hudson/maven/reporters/MavenArtifactRecord.java
          test/pom.xml
          test/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java
          test/src/test/java/hudson/maven/RedeployPublisherTest.java
          test/src/test/java/hudson/model/AbstractProjectTest.java
          http://jenkins-ci.org/commit/core/b3b4ccb0f23bf1769d91ee7535d054ef1937953e
          Log:
          JENKINS-8651 Maven deployment with uniqueVersion == true creating "new" versions for attached artifacts

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Olivier Lamy Path: maven-plugin/pom.xml maven-plugin/src/main/java/hudson/maven/reporters/MavenArtifact.java maven-plugin/src/main/java/hudson/maven/reporters/MavenArtifactRecord.java test/pom.xml test/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java test/src/test/java/hudson/maven/RedeployPublisherTest.java test/src/test/java/hudson/model/AbstractProjectTest.java http://jenkins-ci.org/commit/core/b3b4ccb0f23bf1769d91ee7535d054ef1937953e Log: JENKINS-8651 Maven deployment with uniqueVersion == true creating "new" versions for attached artifacts

          Code changed in jenkins
          User: Olivier Lamy
          Path:
          pom.xml
          src/main/java/hudson/maven/reporters/MavenArtifact.java
          src/main/java/hudson/maven/reporters/MavenArtifactRecord.java
          http://jenkins-ci.org/commit/maven-plugin/595199a20193c71f18783c81b5d0949a06668224
          Log:
          JENKINS-8651 Maven deployment with uniqueVersion == true creating "new" versions for attached artifacts

          Originally-Committed-As: b3b4ccb0f23bf1769d91ee7535d054ef1937953e

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Olivier Lamy Path: pom.xml src/main/java/hudson/maven/reporters/MavenArtifact.java src/main/java/hudson/maven/reporters/MavenArtifactRecord.java http://jenkins-ci.org/commit/maven-plugin/595199a20193c71f18783c81b5d0949a06668224 Log: JENKINS-8651 Maven deployment with uniqueVersion == true creating "new" versions for attached artifacts Originally-Committed-As: b3b4ccb0f23bf1769d91ee7535d054ef1937953e

          Code changed in jenkins
          User: Olivier Lamy
          Path:
          test/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java
          http://jenkins-ci.org/commit/jenkins-test-harness/f06684aee169d83c331ab53a36f201e628d384a5
          Log:
          JENKINS-8651 Maven deployment with uniqueVersion == true creating "new" versions for attached artifacts

          Originally-Committed-As: b3b4ccb0f23bf1769d91ee7535d054ef1937953e

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Olivier Lamy Path: test/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java http://jenkins-ci.org/commit/jenkins-test-harness/f06684aee169d83c331ab53a36f201e628d384a5 Log: JENKINS-8651 Maven deployment with uniqueVersion == true creating "new" versions for attached artifacts Originally-Committed-As: b3b4ccb0f23bf1769d91ee7535d054ef1937953e

            olamy Olivier Lamy
            kphonik Jason Stiefel
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: