Maven Assembly Plugin
  1. Maven Assembly Plugin
  2. MASSEMBLY-67

assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2-beta-1
    • Component/s: None
    • Labels:
      None

      Description

      I'm using the jar plugin to add my dependencies to the manifest. I'm also using the assembly plugin to package all dependencies into one archive. The problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and the archiver adds them as "foo-20041113.jar".

      This causes my snapshot classes to not be found at runtime.

      1. MJAR-28-Notes.txt
        6 kB
        Barrie Treloar
      2. MJAR-28-TestCases-Patch.txt
        43 kB
        Barrie Treloar

        Issue Links

          Activity

          Hide
          Mark J. Titorenko added a comment -

          This issue is cloned from MASSEMBLY-3

          Show
          Mark J. Titorenko added a comment - This issue is cloned from MASSEMBLY-3
          Hide
          Mark J. Titorenko added a comment -

          The issue title should read "assembling dependent jars that contain snapshots" not "assembling dependent jars or snapshots".

          This is still happening. I have a feeling that the assembly is doing the correct thing while the jar plugin is not, so I'll also open an issue within the jar plugin project and link it to this one.

          This seems to occur when snapshot versions have been uploaded to the remote repository. If snapshot versions exist within the local repository then everything works out fine (jars are named version-SNAPSHOT in both plugins).

          Show
          Mark J. Titorenko added a comment - The issue title should read "assembling dependent jars that contain snapshots" not "assembling dependent jars or snapshots". This is still happening. I have a feeling that the assembly is doing the correct thing while the jar plugin is not, so I'll also open an issue within the jar plugin project and link it to this one. This seems to occur when snapshot versions have been uploaded to the remote repository. If snapshot versions exist within the local repository then everything works out fine (jars are named version-SNAPSHOT in both plugins).
          Hide
          Brett Porter added a comment -

          jar plugin seems to be in the wrong.

          However, I'm unsure why you use the jar plugin to write your manifest - shouldn't you add the <archive> section to the assembly plugin?

          Show
          Brett Porter added a comment - jar plugin seems to be in the wrong. However, I'm unsure why you use the jar plugin to write your manifest - shouldn't you add the <archive> section to the assembly plugin?
          Hide
          Barrie Treloar added a comment -

          Brett, could you elaborate please?

          I'm not familiar with the archive section of the assembly plugin, but I am not sure how this would work anyway.
          (I can't find the archive definition at http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html and there is no information about the archive parameter at the mojo decriptions.)

          The jar file needs in META-INF/MANIFEST.MF entries like:

          Class-Path: <dep1> <dep2> etc

          so that I can just run on the command line:

          java -jar <jar file>

          So this would be part of the jar plugin.

          All the assembly's task is to create the correct directory structure so that the project's jar and all dependencies are copied to the correct locations so that the Class-Path declaration matches the file locations.

          Cheers

          Show
          Barrie Treloar added a comment - Brett, could you elaborate please? I'm not familiar with the archive section of the assembly plugin, but I am not sure how this would work anyway. (I can't find the archive definition at http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html and there is no information about the archive parameter at the mojo decriptions.) The jar file needs in META-INF/MANIFEST.MF entries like: Class-Path: <dep1> <dep2> etc so that I can just run on the command line: java -jar <jar file> So this would be part of the jar plugin. All the assembly's task is to create the correct directory structure so that the project's jar and all dependencies are copied to the correct locations so that the Class-Path declaration matches the file locations. Cheers
          Hide
          Brett Porter added a comment -

          <archive> is in the configuration element (like it is for a JAR). I think it should also be supported in the assembly descriptor, but that's a separate issue as it isn't right now.

          http://maven.apache.org/plugins/maven-assembly-plugin/assembly-mojo.html

          So, this allows you to write out the archive configuration if the assembly is producing a JAR in the same way as if you were just producing a JAR.

          Show
          Brett Porter added a comment - <archive> is in the configuration element (like it is for a JAR). I think it should also be supported in the assembly descriptor, but that's a separate issue as it isn't right now. http://maven.apache.org/plugins/maven-assembly-plugin/assembly-mojo.html So, this allows you to write out the archive configuration if the assembly is producing a JAR in the same way as if you were just producing a JAR.
          Hide
          Barrie Treloar added a comment -

          Ok,
          I think the problem is that we are not using the archiver to assemble a jar.

          We are using the archiver to assemble a binary distribution of the jar, with all dependencies.
          Therefore we need the version values in the manifest to match the versions in the binary distribution as well.

          I'm not clear if the Class-Path entry should be -SNAPSHOT or the resolved version identifiers.
          The only reason for a -SNAPSHOT would be for development purposes and so it would be easier to just use -SNAPSHOT rather than the timestamped snapshot versions.

          Show
          Barrie Treloar added a comment - Ok, I think the problem is that we are not using the archiver to assemble a jar. We are using the archiver to assemble a binary distribution of the jar, with all dependencies. Therefore we need the version values in the manifest to match the versions in the binary distribution as well. I'm not clear if the Class-Path entry should be -SNAPSHOT or the resolved version identifiers. The only reason for a -SNAPSHOT would be for development purposes and so it would be easier to just use -SNAPSHOT rather than the timestamped snapshot versions.
          Hide
          Brett Porter added a comment -

          ok, so you aren't producing a jar in the assembly plugin.

          1) you produce a jar with a manifest and main-class and class-path
          2) you produce an assembly (say, zip) that contains the above jar, and the elements of the class-path

          if this is the case, then this can be closed won't fix as there's nothing wrong with the assembly plugin (the bug is the writing of the incorrect class-path in the jar plugin).

          Show
          Brett Porter added a comment - ok, so you aren't producing a jar in the assembly plugin. 1) you produce a jar with a manifest and main-class and class-path 2) you produce an assembly (say, zip) that contains the above jar, and the elements of the class-path if this is the case, then this can be closed won't fix as there's nothing wrong with the assembly plugin (the bug is the writing of the incorrect class-path in the jar plugin).
          Hide
          Barrie Treloar added a comment -

          Ok I have thrown together all my notes that I was using while investigating this.
          I have also included a patch that has integration test cases that show the desired behaviour. I wouldn't be applying those patches to the SCM, just use them locally.

          The error occurs in MavenArchiver at the lines 82-108 in the config.isAddClasspath block.
          The problem is that the classpath is configured from
          project.getRuntimeClasspathElements()
          and appended to the classpath by converting the artifact to a file and use the name part of the file.

          For SNAPSHOT files, these will ALWAYS resolve to -SNAPSHOT, even though it is a duplicate copy of the timestamped version.

          So it looks like MavenArchiver should be using an algorithm similar to Assembly for creating the Class-Path entry. (The code should be refactored so it can be shared)

          However, I could only find MavenArchiver from maven/components/tags/maven-2.0.4
          Does that mean to fix this we have to go to Maven 2.0.5?

          Show
          Barrie Treloar added a comment - Ok I have thrown together all my notes that I was using while investigating this. I have also included a patch that has integration test cases that show the desired behaviour. I wouldn't be applying those patches to the SCM, just use them locally. The error occurs in MavenArchiver at the lines 82-108 in the config.isAddClasspath block. The problem is that the classpath is configured from project.getRuntimeClasspathElements() and appended to the classpath by converting the artifact to a file and use the name part of the file. For SNAPSHOT files, these will ALWAYS resolve to -SNAPSHOT, even though it is a duplicate copy of the timestamped version. So it looks like MavenArchiver should be using an algorithm similar to Assembly for creating the Class-Path entry. (The code should be refactored so it can be shared) However, I could only find MavenArchiver from maven/components/tags/maven-2.0.4 Does that mean to fix this we have to go to Maven 2.0.5?
          Hide
          Barrie Treloar added a comment -

          Woops, I've attached the comments to this bug rather than MJAR-28.
          Never mind, they are related.
          Request for advice sent to dev list, see http://www.nabble.com/MJAR-28-Advice-from-dev%3A-Mainfest.mf-Class-Path-entries-by-MavenArchiver%2C-Assembly-and-Jar-tf1908862.html

          Show
          Barrie Treloar added a comment - Woops, I've attached the comments to this bug rather than MJAR-28 . Never mind, they are related. Request for advice sent to dev list, see http://www.nabble.com/MJAR-28-Advice-from-dev%3A-Mainfest.mf-Class-Path-entries-by-MavenArchiver%2C-Assembly-and-Jar-tf1908862.html
          Hide
          Barrie Treloar added a comment -

          I've reposted my request for help as it has been a week and no response from the dev list.

          Show
          Barrie Treloar added a comment - I've reposted my request for help as it has been a week and no response from the dev list.
          Hide
          Barrie Treloar added a comment -

          (Well it's not quite a week... but) Anyway I've found a web enabled IRC client and asked on the maven irc channel.
          #maven channel on the codehaus IRC server: irc.codehaus.org:6667

          The latest code base (I was struggling to find) is at http://svn.apache.org/repos/asf/maven/shared/trunk/maven-archiver

          Also the correct place for archiver defects is in http://jira.codehaus.org/browse/MNG using the maven-archiver component.

          Show
          Barrie Treloar added a comment - (Well it's not quite a week... but) Anyway I've found a web enabled IRC client and asked on the maven irc channel. #maven channel on the codehaus IRC server: irc.codehaus.org:6667 The latest code base (I was struggling to find) is at http://svn.apache.org/repos/asf/maven/shared/trunk/maven-archiver Also the correct place for archiver defects is in http://jira.codehaus.org/browse/MNG using the maven-archiver component.
          Hide
          Barrie Treloar added a comment -

          I have provided refactoring, test cases and a patch to fix this bug on MNG-2456, as it is not really a problem with the assembler.

          I think the tight coupling of maven-archiver and assembler means that the use of outputFileNameMapping in dependencySet should be deprecated as these filenames must match.

          Show
          Barrie Treloar added a comment - I have provided refactoring, test cases and a patch to fix this bug on MNG-2456, as it is not really a problem with the assembler. I think the tight coupling of maven-archiver and assembler means that the use of outputFileNameMapping in dependencySet should be deprecated as these filenames must match.
          Hide
          John Casey added a comment -

          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.

          I've added an integration test: /basic-features/outputFileNameMapping-withArtifactBaseVersion to verify that this is fixed.

          Show
          John Casey added a comment - 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. I've added an integration test: /basic-features/outputFileNameMapping-withArtifactBaseVersion to verify that this is fixed.
          Hide
          Richard van der Hoff added a comment -

          Is this supposed to work for current versions of the assembly plugin? I've tried putting an outputFileNameMapping in my dependencySet, but it doesn't seem to make any difference.

          Show
          Richard van der Hoff added a comment - Is this supposed to work for current versions of the assembly plugin? I've tried putting an outputFileNameMapping in my dependencySet, but it doesn't seem to make any difference.
          Hide
          Brett Porter added a comment -

          Richard: the fix for is 2.2, which is the current SVN version - it is not released.

          Show
          Brett Porter added a comment - Richard: the fix for is 2.2, which is the current SVN version - it is not released.
          Hide
          Richard van der Hoff added a comment -

          ah right, thanks. I'll look into rolling my own build of it then...

          Show
          Richard van der Hoff added a comment - ah right, thanks. I'll look into rolling my own build of it then...
          Hide
          Barrie Treloar added a comment -

          I wrote up the steps I did to roll my own:
          http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins

          Show
          Barrie Treloar added a comment - I wrote up the steps I did to roll my own: http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins
          Hide
          Rudyolph Bistrovich added a comment -

          Don't you guys think it is an issue that depending on who did the deploy of the snapshot and who is doing the assembly you will have different results? ie.
          I wrote and deployed the snapshot and then do the assembly...dependency jars come out with -SNAPSHOT
          One of my developers does the assembly...dependency jars come out with the datestamp.

          We now have two flavours of assemblies zips that can wreak havok with predefined classpaths.

          It sounds like this is an issue with the deploy plugin itself since it should be consistent no matter who actually did the deploy.

          Show
          Rudyolph Bistrovich added a comment - Don't you guys think it is an issue that depending on who did the deploy of the snapshot and who is doing the assembly you will have different results? ie. I wrote and deployed the snapshot and then do the assembly...dependency jars come out with -SNAPSHOT One of my developers does the assembly...dependency jars come out with the datestamp. We now have two flavours of assemblies zips that can wreak havok with predefined classpaths. It sounds like this is an issue with the deploy plugin itself since it should be consistent no matter who actually did the deploy.
          Hide
          David Boden added a comment -

          Please see MASSEMBLY-91 for a description of a further problem with jars with classifiers and a workaround that you can use.

          Show
          David Boden added a comment - Please see MASSEMBLY-91 for a description of a further problem with jars with classifiers and a workaround that you can use.
          Hide
          craigb added a comment - - edited

          I just had problems somewhat related to this issue, but instead I was trying to get all timestamps for my snapshots. I wrote up my findings under another closed jira http://jira.codehaus.org/browse/MASSEMBLY-211?focusedCommentId=259987&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_259987

          Show
          craigb added a comment - - edited I just had problems somewhat related to this issue, but instead I was trying to get all timestamps for my snapshots. I wrote up my findings under another closed jira http://jira.codehaus.org/browse/MASSEMBLY-211?focusedCommentId=259987&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_259987

            People

            • Assignee:
              John Casey
              Reporter:
              Mark J. Titorenko
            • Votes:
              4 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development