maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig (JIRA)" <j...@codehaus.org>
Subject [jira] Commented: (MASSEMBLY-211) assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names
Date Mon, 14 Mar 2011 05:27:22 GMT

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

Craig commented on MASSEMBLY-211:
---------------------------------

I just ran into this problem using maven-assembly-plugin-2.2 and maven 3.0.2.

maven-archiver in the maven-jar-plugin writes timestamped artifact ids into the manifest Class-Path,
but maven-assembly-plugin writes sometimes unique timestamps, and sometimes non-unique snapshots.

The workaround is to force both maven-archiver (using the useUniqueVersions flag) and maven-assembly-plugin
(using the outputFileNameMapping flag) to always use non-unique snapshots, rather than timestamped
snapshots.

I tried understanding why this issue occurs, but got lost in a labyrinth of runtime selected
dependency resolution code in the core of maven. But I believe the crux of the problem is
that maven-assembly-plugin calls org.apache.maven.artifact.resolver.ArtifactResolver.resolveTransitively()
on the dependency set. It is this call which changes Artifact.version from e.g. 1.0-20110130.220039-25
to 1.0-SNAPSHOT. Now both version and baseVersion contain 1.0-SNAPSHOT, and therefore it is
impossible to get the timestamped result I was after.

maven-archiver doesn't suffer this problem because it doesn't call any (deprecated?) resolution
code. Instead it simply uses MavenProject.getArtifacts() which the documentation says includes
all transitive dependencies (as long as the phase has already forced them to be resolved).

> 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
>            Assignee: John Casey
>            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

        

Mime
View raw message