[
http://jira.codehaus.org/browse/MASSEMBLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104913
]
Max Bowsher commented on MASSEMBLY-211:
---------------------------------------
Problem: The jar plugin and the assembly plugin independently construct a list
of artifact filenames:
* the jar plugin builds the Class-Path manifest attribute
* the assembly plugin builds the actual directory of jar files
They do not, in the presence of deployed uniqueVersioned snapshots, reliably
produce the same filename. This disagreement breaks things.
> 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-2
>
>
> 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
