Uploaded image for project: 'Maven Assembly Plugin'
  1. Maven Assembly Plugin
  2. MASSEMBLY-91

Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp ex. api-authorisation-4.00-20060502.150651-20.jar

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.1
    • Fix Version/s: 2.2-beta-1
    • Component/s: None
    • Labels:
      None
    • Environment:
      Win XP, Java 1.5

      Description

      Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp ex. api-authorisation-4.00-20060502.150651-20.jar. Would it be possible to offer a flag on the plugin so that this behaviour could be turned off and the file could remain as api-authorisation-SNAPSHOT.jar?

      The renaming of the files causes the files to become invalid when compiling native or CSharp binaries inside of maven.

      Thanks,

      Chris Stevenson

        Issue Links

          Activity

          Hide
          ctrueden Curtis Rueden added a comment -

          David: You can avoid using two separate configurations with the "$

          {dashClassifier?}" syntax:

          <outputFileNameMapping>${artifact.artifactId}-${artifact.baseVersion}${dashClassifier?}

          .$

          {artifact.extension}

          </outputFileNameMapping>

          Show
          ctrueden Curtis Rueden added a comment - David: You can avoid using two separate configurations with the "$ {dashClassifier?}" syntax: <outputFileNameMapping>${artifact.artifactId}-${artifact.baseVersion}${dashClassifier?} .$ {artifact.extension} </outputFileNameMapping>
          Hide
          daveboden David Boden added a comment - - edited

          We initially used an output file mapping of
          <outputFileNameMapping>$

          {artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}</outputFileNameMapping>

          But we have a couple of jars with a "config" classifier (e.g. myartifact-3.2-config.jar)

          You can't just include classifier:
          <outputFileNameMapping>${artifact.artifactId}

          -$

          {artifact.baseVersion}

          -$

          {artifact.classifier}.${artifact.extension}</outputFileNameMapping>

          Because if you do, any artifacts that don't have a classifier will end up being named something like:
          myotherartifact-3.3-${artifact.classifier}

          .jar

          The current solution we have in place is to have two separate <dependencySet/> configurations, one with an <include/> of

          *:*:*:config

          and the other with an <exclude/> of

          *:*:*:config

          . Hope this works for you if you have the same issue. Ultimately, I do think we need a flag to control this behaviour; especially taking into account how ugly the workaround is for classifiers. It doubles the time taken for the build.

          Show
          daveboden David Boden added a comment - - edited We initially used an output file mapping of <outputFileNameMapping>$ {artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}</outputFileNameMapping> But we have a couple of jars with a "config" classifier (e.g. myartifact-3.2-config.jar) You can't just include classifier: <outputFileNameMapping>${artifact.artifactId} -$ {artifact.baseVersion} -$ {artifact.classifier}.${artifact.extension}</outputFileNameMapping> Because if you do, any artifacts that don't have a classifier will end up being named something like: myotherartifact-3.3-${artifact.classifier} .jar The current solution we have in place is to have two separate <dependencySet/> configurations, one with an <include/> of *:*:*:config and the other with an <exclude/> of *:*:*:config . Hope this works for you if you have the same issue. Ultimately, I do think we need a flag to control this behaviour; especially taking into account how ugly the workaround is for classifiers. It doubles the time taken for the build.
          Hide
          jdcasey 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
          jdcasey 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
          chris.stevenson@gmail.com Chris added a comment -

          Sorry, just to clairy, when the flag is set to false all snapshots in the assembly end up as foo-SNAPSHOT.type.

          Cheers,

          Chris

          Show
          chris.stevenson@gmail.com Chris added a comment - Sorry, just to clairy, when the flag is set to false all snapshots in the assembly end up as foo-SNAPSHOT.type. Cheers, Chris
          Hide
          chris.stevenson@gmail.com Chris added a comment -

          Brett,

          I've checked this issue:

          http://jira.codehaus.org/browse/MASSEMBLY-67

          And it says that the problem has been resolved but for myself and possibly the guy who is using the native plugin this is still a problem.

          The problem is that when you are bring down dependencies for a library to distribute and one of your deps is at snapshot, instead of the jar being included in the archive as foo-SNAPSHOT.jar it gets included as foo-2006-04-08-01.....jar. This shouldn't cause a big issue with Java apps but causes a massive issue with C# apps, as the name of the file is burnt into the binary on compilation.

          Is there anyway to have an attribute ex <timeStampedSnapshots> which is defaulted to true but can be turned off when using native or dotnet libraries?

          Many thanks,

          Chris

          Show
          chris.stevenson@gmail.com Chris added a comment - Brett, I've checked this issue: http://jira.codehaus.org/browse/MASSEMBLY-67 And it says that the problem has been resolved but for myself and possibly the guy who is using the native plugin this is still a problem. The problem is that when you are bring down dependencies for a library to distribute and one of your deps is at snapshot, instead of the jar being included in the archive as foo-SNAPSHOT.jar it gets included as foo-2006-04-08-01.....jar. This shouldn't cause a big issue with Java apps but causes a massive issue with C# apps, as the name of the file is burnt into the binary on compilation. Is there anyway to have an attribute ex <timeStampedSnapshots> which is defaulted to true but can be turned off when using native or dotnet libraries? Many thanks, Chris

            People

            • Assignee:
              jdcasey John Casey
              Reporter:
              chris.stevenson@gmail.com Chris
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development