Maven 2.x Assembly Plugin

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

duplicates

Bug - A problem which impairs or prevents the functions of the product. MASSEMBLY-67 assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: