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

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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: maven-plugin
    • Labels:
      None
    • Environment:
      Hudson 1.395
    • Similar Issues:

      Description

      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

        Attachments

          Issue Links

            Activity

            Hide
            kphonik 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!

            Show
            kphonik 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!
            Hide
            kphonik 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.

            Show
            kphonik 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.
            Hide
            olamy Olivier Lamy added a comment -

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

            Show
            olamy Olivier Lamy added a comment - Nice do you have time to provide a patch ? Thanks !
            Hide
            kphonik 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.

            Show
            kphonik 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.
            Hide
            olamy Olivier Lamy added a comment -

            fixed in more simple way.
            Will be in 1.398

            Show
            olamy Olivier Lamy added a comment - fixed in more simple way. Will be in 1.398
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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

              People

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

                Dates

                Created:
                Updated:
                Resolved: