[
http://jira.codehaus.org/browse/MASSEMBLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128541#action_128541
]
John Casey commented on MASSEMBLY-211:
--------------------------------------
Can you attach an assembly descriptor that creates the erroneous result? It
looks like your problem might be solved by using ${artifact.baseVersion}
instead of ${artifact.version} in the outputFileNameMapping, which is probably
what the jar plugin is doing when it creates the Class-Path manifest entry.
I'll look into how the jar plugin handles this, but we need to provide
flexibility to do both, IMO.
> assembly plugin and jar plugin disagree about whether to use uniqueVersion
> snapshot names
> -----------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-211
> URL: http://jira.codehaus.org/browse/MASSEMBLY-211
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2-beta-1
> Reporter: Max Bowsher
> Priority: Blocker
> Fix For: 2.2-beta-3
>
> Attachments: CSMDirectoryListingOfJars.txt, CSMJarManifest.txt
>
>
> Background: Consider the following setup:
> jar-plugin configured with addClasspath=true, writing list of dependency jar
> file names into manifest of project jar.
> assembly-plugin configured with a dependencySet pulling all dependencies into
> a single directory.
> Result: application is runnable with with "java -jar mainartifact.jar"
> There has long been a problem (i.e. with assembly-plugin 2.1) that when
> deployed snapshot jars were in use, the jar and assembly plugins would
> disagree in whether the uniqueVersion name was used, and this is MNG-2456.
> However, assembly-plugin 2.2-beta-1 has introduced further complications to
> the situation by not using the lifecycle's default set of resolved artifacts,
> but by running a manual resolution of its own. This has made the two plugins
> disagree in more scenarios than before, and broke the workaround patch that I
> posted in MNG-2456.
> At the root of these problems is some very peculiar handling of the 'file',
> 'baseVersion' and 'version' fields of Artifact objects, two notable instances
> of which are the DefaultArtifact.isSnapshot method, which despite being an
> accessor, actually changes the state of the object, and the
> DefaultArtifactResolver.resolve method, which contains some rather bizarre
> manipulation of the 'file' field (more detail may comments in MNG-2456).
> An interim fix to this issue might involve workarounds in both the jar and
> assembly plugins to get them to agree. A true fix probably also involves
> fixing Maven core classes.
--
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
