[
http://jira.codehaus.org/browse/MASSEMBLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-211:
---------------------------------
Description:
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.
was:
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.
Fix Version/s: 2.2-beta-2
> 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
