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 New Feature
    • Status: Closed Closed
    • Priority: Major 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
    • Number of attachments :
      0

      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
          Chris Stevenson 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 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
          Hide
          Chris Stevenson 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 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
          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
          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
          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
          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
          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>

            People

            • Assignee:
              John Casey
              Reporter:
              Chris Stevenson
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: