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

"deploy unique version" use distinc sequence number per artifact

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • maven-plugin
    • None
    • Platform: All, OS: All

      When hudson is used to deploy maven artifacts + the "unique version" advanced
      option is checked, and the built project has multiple artifacts (a POM, a JAR, a
      sources-JAR for example), each of them get a dedicated unique version number.
      The same feature on the maven-deploy-plugin use the same unique version for all
      artifacts, so it's easy to know they are related.

          [JENKINS-2593] "deploy unique version" use distinc sequence number per artifact

          tjuerge added a comment -
              • Issue 3518 has been marked as a duplicate of this issue. ***

          tjuerge added a comment - Issue 3518 has been marked as a duplicate of this issue. ***

          tjuerge added a comment -

          As already suggested by Thomas: It seems that deploying attached artifacts via
          an instance of ArtifactDeployer retrieved MavenEmbedder in
          MavenArtifactRecord.deploy() increments <buildNumber> in
          "maven-metadata-<repoid>.xml".

          Maybe is is an issue with an outdated version of MavenEmbedder used with Hudson.

          tjuerge added a comment - As already suggested by Thomas: It seems that deploying attached artifacts via an instance of ArtifactDeployer retrieved MavenEmbedder in MavenArtifactRecord.deploy() increments <buildNumber> in "maven-metadata-<repoid>.xml". Maybe is is an issue with an outdated version of MavenEmbedder used with Hudson.

          tjuerge added a comment -

          Btw. the logging of deploying attached artifacts could be improved by printing
          the filename of the attached artifact instead of the main artifacts one:

          Index: MavenArtifactRecord.java
          ===================================================================
          — MavenArtifactRecord.java (revision 18451)
          +++ MavenArtifactRecord.java (working copy)
          @@ -119,8 +119,8 @@

          deployer.deploy(main.getFile(),main,deploymentRepository,embedder.getLocalRepository());

          for (MavenArtifact aa : attachedArtifacts)

          { - logger.println(Messages.MavenArtifact_DeployingAttachedArtifact(main.getFile().getName())); Artifact a = aa.toArtifact(handlerManager,factory, parent); + logger.println(Messages.MavenArtifact_DeployingAttachedArtifact(a.getFile().getName())); deployer.deploy(a.getFile(),a,deploymentRepository,embedder.getLocalRepository()); }

          }

          tjuerge added a comment - Btw. the logging of deploying attached artifacts could be improved by printing the filename of the attached artifact instead of the main artifacts one: Index: MavenArtifactRecord.java =================================================================== — MavenArtifactRecord.java (revision 18451) +++ MavenArtifactRecord.java (working copy) @@ -119,8 +119,8 @@ deployer.deploy(main.getFile(),main,deploymentRepository,embedder.getLocalRepository()); for (MavenArtifact aa : attachedArtifacts) { - logger.println(Messages.MavenArtifact_DeployingAttachedArtifact(main.getFile().getName())); Artifact a = aa.toArtifact(handlerManager,factory, parent); + logger.println(Messages.MavenArtifact_DeployingAttachedArtifact(a.getFile().getName())); deployer.deploy(a.getFile(),a,deploymentRepository,embedder.getLocalRepository()); } }

          godin added a comment -

          We have the same problem when using attached to pom assemblies. And I can
          provide test project or steps to reproduce this.

          godin added a comment - We have the same problem when using attached to pom assemblies. And I can provide test project or steps to reproduce this.

          thoaan added a comment -

          This issue has been marked as critical and in progress, but it doesn't seem like anything has been done in a while. It is still unassigned and seems to be forgotten. It would be nice to get a status on this issue, and if we can expect it do be solved in the nearby future.

          We have this problem on Hudson version 1.345 and Maven 2.09.

          thoaan added a comment - This issue has been marked as critical and in progress, but it doesn't seem like anything has been done in a while. It is still unassigned and seems to be forgotten. It would be nice to get a status on this issue, and if we can expect it do be solved in the nearby future. We have this problem on Hudson version 1.345 and Maven 2.09.

          saimad added a comment -

          Running into the same issue. Not sure if there is a workaround for this. Would greatly appreciate if anyone could post workarounds or recommendations to solve this issue.

          saimad added a comment - Running into the same issue. Not sure if there is a workaround for this. Would greatly appreciate if anyone could post workarounds or recommendations to solve this issue.

          tedd4u added a comment -

          Has anyone else that commented found a reasonable workaround? Uniquely identified artifacts are a basic and essential need for us.

          tedd4u added a comment - Has anyone else that commented found a reasonable workaround? Uniquely identified artifacts are a basic and essential need for us.

          This will become a problem with Maven 3, since Maven 3 does only use the timestamped variant.

          Stephan Pauxberger added a comment - This will become a problem with Maven 3, since Maven 3 does only use the timestamped variant.

          Likewise running into this with Hudson 1.396 (I know, I know, I should upgrade) and Maven 3.0.3

          It breaks subsequent builds that depend these components because the highest build number is used to determine which version to retrieve. Since only the jar exists for the "attached" artifact of that version (in this case, the tests jar), the build tries to download the highest version available, but of the main artifacts (POM, jar, etc) and fails.

          Adrian Wilkins added a comment - Likewise running into this with Hudson 1.396 (I know, I know, I should upgrade) and Maven 3.0.3 It breaks subsequent builds that depend these components because the highest build number is used to determine which version to retrieve. Since only the jar exists for the "attached" artifact of that version (in this case, the tests jar), the build tries to download the highest version available, but of the main artifacts (POM, jar, etc) and fails.

          Can confirm that Jenkins 1.429 and Maven 3.0.3 do NOT exhibit this issue.

          Had tried upgrading to Hudson 2.1.1 to see if this issue would be fixed, but it was so incompatible with the existing Hudson 1.396 environment that half our jobs disappeared (refused to load). Somewhat annoyingly, the Hudson crew appear to have broken core parts of the SCM APIs, and the newer SVN plugin causes Jenkins to choke in a lot of places - but a swift poke around in the source code and a plugin downgrade and we're all happy again.

          Adrian Wilkins added a comment - Can confirm that Jenkins 1.429 and Maven 3.0.3 do NOT exhibit this issue. Had tried upgrading to Hudson 2.1.1 to see if this issue would be fixed, but it was so incompatible with the existing Hudson 1.396 environment that half our jobs disappeared (refused to load). Somewhat annoyingly, the Hudson crew appear to have broken core parts of the SCM APIs, and the newer SVN plugin causes Jenkins to choke in a lot of places - but a swift poke around in the source code and a plugin downgrade and we're all happy again.

            Unassigned Unassigned
            ndeloof Nicolas De Loof
            Votes:
            12 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: