assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names

Can you please enumerate the problems/disagreements between these two plugins, so we can address them? Currently, this is more of a general stylistic complaint than an actionable issue.

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.

I'm seeing this problem on Maven 2.0.7

Because of MDEPLOY-57, I end up getting unique versions of JARs in my repository even when I have explicitly declared <uniqueVersion>false</uniqueVersion>

Thus, this ripples and is made even worse by MASSEMBLY-211 because now my assembly:assembly pulls unique versioned jars into the assembly (ZIP), but the jar:jar command (when told to write a mainfest with a main class and classpath) points to all the non-unique-versioned jars.

Thus, the classpath on the jar's manifest points to (for example) ccbs-config-common-server-1.0.M2.jar while the actual zip pulled down by assembly:assembly is ccbs-config-common-server-1.0.M2-20070814.152448-16.jar

Thus, the application cannot be executed.

This is a directory listing of the JARs that are pulled by assembly:assembly for comparison to the manifest which I'm also attaching which is produced by jar:jar for the same project.

For comparison to CSMDirectoryListingOfJars.txt List of jars in the executable JAR manifest produced by JAR:JAR does not match the list of JARs pulled by ASSEMBLY:ASSEMBLY

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.

At best, using baseVersion would be a workaround only. If I use a deployed snapshot, the uniqueVersion naming is metadata that should be allowed to persist into the assembly, to identify the exact version of the dependency being used.

artifact-path handling needs to be consolidated somehow between the assembly plugin and the component used to generate manifest files. This includes formatting of the file names (or, determining when to use the 'native' file path vs. a formatted one that would result from the file being copied to the formatted location), but it also includes support for mapping artifacts to specific subpaths within a directory structure, such as would be needed if all dependencies were archived in the /lib directory of a jar whose Class-Path manifest attribute attempted to reference them.

The mappings and formats need to then be made available to all plugins that generate manifests. In the case of an assembly that consists of the project's main jar with its dependencies listed in the /lib subpath, the jar:jar mojo needs to know about this subpath when it generates the manifest, so its actions are coordinated with those of the assembly plugin.

I would therefore propose a new plugin that will generate jar manifest files. The manifest files will then be available for use in any plugin that supports the MavenArchiveConfiguration from maven-archiver. In order to take advantage of existing configurations, the plugin should also support providers that can generate a Class-Path or other attribute based on some other configuration in the project - with the first example being the dependencySets section of an assembly descriptor. With an assembly provider, the assembly descriptor can be read in order to determine to which path each artifact included should be mapped.

The fix for this issue is the same as the fix for MSHARED-32. Once maven-archiver 2.4 is released, it can be incorporated here.

This is fixed by MSHARED-32 and MSHARED-36. Classpath-handling improvements in maven-archiver 2.4-SNAPSHOT are documented on the maven-archiver website (or will be, once 2.4 is released).

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).

We are seeing this problem as well using 2.2.1 We have both the jar and assembly plugin working together to produce a zip file that contains an executable jar (produced with the jar plugin including a manifest that has all dependencies) and all the jar library dependencies as well.

The problem we are seeing is probably the same or similar to what you were having, I see some jars with timestamps (we are using SNAPSHOTS for development) but there is one of them that has not time stamp... and in the manifest its being looked for with a timestamp. So this "disagreement" between the assembly and jar plugin create class not found exceptions on run time.

Related bug report:
MASSEMBLY-584

Hellmut, please comment and vote for MASSEMBLY-584, since it seems to be exactly the same case you have described (or very similar).

Cheers,
Donatas