Maven Shared Components
  1. Maven Shared Components
  2. MSHARED-36

Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots

    Details

    • Testcase included:
      yes
    • Number of attachments :
      5

      Description

      See related problems MJAR-28 and MASSEMBLY-67.

      Summary:

      The Maven-Archiver uses the file part of the artifact's filename to create the Class-Path entries in the Manifest.
      This works fine for released artifacts and non-deployed snapshot.
      The problem occurs when using a deployed snapshot as the assembly plugin will copy the dependency as $

      {artifactId}-${version}-timestampedversion.jar and the entry in the Class-Path will be ${artifactId}

      -$

      {version}

      -SNAPSHOT
      thus use of java -jar <jarfile> will fail because of the differing names.

      1. MNG-2456-maxb.patch
        6 kB
        Max Bowsher
      2. MNG-2456-patch.txt
        25 kB
        Barrie Treloar
      3. MNG-2456-step1-refactoring-patch.txt
        20 kB
        Barrie Treloar
      4. MNG-2456-step2-add-test-cases-patch.txt
        25 kB
        Barrie Treloar
      5. MNG-2456-step3-fix-bug-patch.txt
        25 kB
        Barrie Treloar

        Issue Links

          Activity

          Hide
          Barrie Treloar added a comment -

          Attached refactoring patch, with appropriate test cases, that changes Maven Archiver to use Project.getRuntimeArtifacts instead of Project.getRuntimeClasspathElements.

          Show
          Barrie Treloar added a comment - Attached refactoring patch, with appropriate test cases, that changes Maven Archiver to use Project.getRuntimeArtifacts instead of Project.getRuntimeClasspathElements.
          Hide
          Barrie Treloar added a comment -

          Test Cases that exercise the problems.
          (Unfortunately the patch also includes previous steps)

          Show
          Barrie Treloar added a comment - Test Cases that exercise the problems. (Unfortunately the patch also includes previous steps)
          Hide
          Barrie Treloar added a comment -

          Patch to fix the bug and get working unit test
          (Unfortunately the patch also includes previous steps)

          Show
          Barrie Treloar added a comment - Patch to fix the bug and get working unit test (Unfortunately the patch also includes previous steps)
          Hide
          Barrie Treloar added a comment -

          Oops. Classpath is missing file extension...
          Need to update tests and repatch.

          Show
          Barrie Treloar added a comment - Oops. Classpath is missing file extension... Need to update tests and repatch.
          Hide
          Barrie Treloar added a comment -

          Patch adds the type of the artifact to the classpath which was incorrectly left off.

          Show
          Barrie Treloar added a comment - Patch adds the type of the artifact to the classpath which was incorrectly left off.
          Hide
          Barrie Treloar added a comment -

          In MASSEMBLY-67 John Casey says

          The solution here is to use an outputFileNameMapping such as this:

          $

          {artifactId}

          -$

          {baseVersion}.${extension}

          Using ${baseVersion}

          for cases where you want to preserve the -SNAPSHOT naming, the plugin retains the ability to use $

          {version}

          for the timestamp-buildnumber naming, which is useful for describing the exact library version included in the assembly.

          Show
          Barrie Treloar added a comment - In MASSEMBLY-67 John Casey says The solution here is to use an outputFileNameMapping such as this: $ {artifactId} -$ {baseVersion}.${extension} Using ${baseVersion} for cases where you want to preserve the -SNAPSHOT naming, the plugin retains the ability to use $ {version} for the timestamp-buildnumber naming, which is useful for describing the exact library version included in the assembly.
          Hide
          Max Bowsher added a comment -

          I think this issue should be reopened. It is true that an outputFileNameMapping can provide a workaround, but that's only a workaround, not a fix.

          Show
          Max Bowsher added a comment - I think this issue should be reopened. It is true that an outputFileNameMapping can provide a workaround, but that's only a workaround, not a fix.
          Hide
          Max Bowsher added a comment -

          I think the true issue is in the core component maven-artifact-manager, in the DefaultArtifactResolver class - which, in the case of a snapshot version, explicitly overrides the artifact's file property from the "version" name to the "baseVersion" name. Search for the line "artifact.setFile( copy );" to find the relevant place in the code. I suggest that that line should simply be deleted, allowing artifact.getName() to remain returning the "version" name.

          Show
          Max Bowsher added a comment - I think the true issue is in the core component maven-artifact-manager, in the DefaultArtifactResolver class - which, in the case of a snapshot version, explicitly overrides the artifact's file property from the "version" name to the "baseVersion" name. Search for the line "artifact.setFile( copy );" to find the relevant place in the code. I suggest that that line should simply be deleted, allowing artifact.getName() to remain returning the "version" name.
          Hide
          Max Bowsher added a comment -

          Since I cannot override a core component from a POM, I have made a workaround that fixes the behaviour at the maven-archiver level. I am attaching a patch against maven-archiver-2.2.

          My patch is generally along the same fundamental approach as Baerrach's, but with the following differences:

          • aims to fix the problem with minimal changes, instead of including refactoring mixed with the fix.
          • applies the fix to the jar indexing codepath too.
          • tries to avoid hardcoding the details of how to construct artifact filenames.

          In that last point, it is only partially successful - I could not work out how to get hold of an appropriate ArtifactRepository object within maven-archiver, so I resorted to making the twin assumptions:
          1. that the existing filepath would contain the correct path, and only the basename need be fixed up.
          2. that a DefaultRepositoryLayout object would give me the correct basename.

          In practice this seems to work, even if it is a little ugly.

          Show
          Max Bowsher added a comment - Since I cannot override a core component from a POM, I have made a workaround that fixes the behaviour at the maven-archiver level. I am attaching a patch against maven-archiver-2.2. My patch is generally along the same fundamental approach as Baerrach's, but with the following differences: aims to fix the problem with minimal changes, instead of including refactoring mixed with the fix. applies the fix to the jar indexing codepath too. tries to avoid hardcoding the details of how to construct artifact filenames. In that last point, it is only partially successful - I could not work out how to get hold of an appropriate ArtifactRepository object within maven-archiver, so I resorted to making the twin assumptions: 1. that the existing filepath would contain the correct path, and only the basename need be fixed up. 2. that a DefaultRepositoryLayout object would give me the correct basename. In practice this seems to work, even if it is a little ugly.
          Hide
          Christian Goetze added a comment -

          I would like to see a fix that does not involve adding extra configuration items to the assembly... whatever happened to "convention instead of configuration" - and yes, the onus is on you to determine which behaviour should be "standard"...

          Show
          Christian Goetze added a comment - I would like to see a fix that does not involve adding extra configuration items to the assembly... whatever happened to "convention instead of configuration" - and yes, the onus is on you to determine which behaviour should be "standard"...
          Hide
          Matthew McCullough added a comment - - edited

          The assembly:assembly behavior that uses the timestamped JAR name causes a disagreement with jar:jar thus resulting in a zip package that can't be executed since the jar names in the manifest are "simple names" and the jars actually delivered in the ZIP assembly are the date-stamped ones.

          Show
          Matthew McCullough added a comment - - edited The assembly:assembly behavior that uses the timestamped JAR name causes a disagreement with jar:jar thus resulting in a zip package that can't be executed since the jar names in the manifest are "simple names" and the jars actually delivered in the ZIP assembly are the date-stamped ones.
          Hide
          brianfox brianfox added a comment -

          Can someone produce an IT for this?

          Show
          brianfox brianfox added a comment - Can someone produce an IT for this?
          Hide
          manuel aldana added a comment -

          i got same problem. for the start i workarounded this by setting <uniqueVersion>false</uniqueVersion> in distribution management for snapshots.

          Show
          manuel aldana added a comment - i got same problem. for the start i workarounded this by setting <uniqueVersion>false</uniqueVersion> in distribution management for snapshots.
          Hide
          darbois tomas added a comment - - edited

          Error

          Show
          darbois tomas added a comment - - edited Error
          Hide
          John Casey added a comment - - edited

          I've changed the manifest creation logic to use the timestamp/buildnumber version by default (when the classpathLayoutType is simple - the default value - or repository, which makes it act like a maven repo dir structure). The repo output looks like:

          org/codehaus/plexus/plexus-archiver/1.0-alpha-11-SNAPSHOT/plexus-archiver-1.0-alpha-11-20081022.112233-1.jar
          

          You could always specify a custom classpathLayoutType and customClasspathLayout configuration to modify this.

          See MSHARED-32 for more info on the custom layout stuff.

          Show
          John Casey added a comment - - edited I've changed the manifest creation logic to use the timestamp/buildnumber version by default (when the classpathLayoutType is simple - the default value - or repository, which makes it act like a maven repo dir structure). The repo output looks like: org/codehaus/plexus/plexus-archiver/1.0-alpha-11-SNAPSHOT/plexus-archiver-1.0-alpha-11-20081022.112233-1.jar You could always specify a custom classpathLayoutType and customClasspathLayout configuration to modify this. See MSHARED-32 for more info on the custom layout stuff.

            People

            • Assignee:
              John Casey
              Reporter:
              Barrie Treloar
            • Votes:
              9 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: