maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Boden (JIRA)" <j...@codehaus.org>
Subject [jira] Issue Comment Edited: (MASSEMBLY-91) Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp ex. api-authorisation-4.00-20060502.150651-20.jar
Date Tue, 01 Mar 2011 13:00:22 GMT

    [ http://jira.codehaus.org/browse/MASSEMBLY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258086#action_258086
] 

David Boden edited comment on MASSEMBLY-91 at 3/1/11 6:58 AM:
--------------------------------------------------------------

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 {noformat}*:*:*:config{noformat} and the other with an <exclude/>
of {noformat}*:*:*:config{noformat}. 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.

      was (Author: daveboden):
    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.
  
> Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp ex. api-authorisation-4.00-20060502.150651-20.jar
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MASSEMBLY-91
>                 URL: http://jira.codehaus.org/browse/MASSEMBLY-91
>             Project: Maven 2.x Assembly Plugin
>          Issue Type: New Feature
>    Affects Versions: 2.0.1
>         Environment: Win XP, Java 1.5
>            Reporter: Chris Stevenson
>            Assignee: John Casey
>             Fix For: 2.2-beta-1
>
>
> 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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message