Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots

Attached refactoring patch, with appropriate test cases, that changes Maven Archiver to use Project.getRuntimeArtifacts instead of Project.getRuntimeClasspathElements.

Patch to fix the bug and get working unit test
(Unfortunately the patch also includes previous steps)

Oops. Classpath is missing file extension...
Need to update tests and repatch.

Patch adds the type of the artifact to the classpath which was incorrectly left off.

In MASSEMBLY-67 John Casey says

The solution here is to use an outputFileNameMapping such as this:

$

-$

for cases where you want to preserve the -SNAPSHOT naming, the plugin retains the ability to use $

for the timestamp-buildnumber naming, which is useful for describing the exact library version included in the assembly.

I think this issue should be reopened. It is true that an outputFileNameMapping can provide a workaround, but that's only a workaround, not a fix.

I think the true issue is in the core component maven-artifact-manager, in the DefaultArtifactResolver class - which, in the case of a snapshot version, explicitly overrides the artifact's file property from the "version" name to the "baseVersion" name. Search for the line "artifact.setFile( copy );" to find the relevant place in the code. I suggest that that line should simply be deleted, allowing artifact.getName() to remain returning the "version" name.

Since I cannot override a core component from a POM, I have made a workaround that fixes the behaviour at the maven-archiver level. I am attaching a patch against maven-archiver-2.2.

My patch is generally along the same fundamental approach as Baerrach's, but with the following differences:

• aims to fix the problem with minimal changes, instead of including refactoring mixed with the fix.
• applies the fix to the jar indexing codepath too.
• tries to avoid hardcoding the details of how to construct artifact filenames.

In that last point, it is only partially successful - I could not work out how to get hold of an appropriate ArtifactRepository object within maven-archiver, so I resorted to making the twin assumptions:
1. that the existing filepath would contain the correct path, and only the basename need be fixed up.
2. that a DefaultRepositoryLayout object would give me the correct basename.

In practice this seems to work, even if it is a little ugly.

I would like to see a fix that does not involve adding extra configuration items to the assembly... whatever happened to "convention instead of configuration" - and yes, the onus is on you to determine which behaviour should be "standard"...

The assembly:assembly behavior that uses the timestamped JAR name causes a disagreement with jar:jar thus resulting in a zip package that can't be executed since the jar names in the manifest are "simple names" and the jars actually delivered in the ZIP assembly are the date-stamped ones.

Can someone produce an IT for this?

i got same problem. for the start i workarounded this by setting <uniqueVersion>false</uniqueVersion> in distribution management for snapshots.

Error

I've changed the manifest creation logic to use the timestamp/buildnumber version by default (when the classpathLayoutType is simple - the default value - or repository, which makes it act like a maven repo dir structure). The repo output looks like:

org/codehaus/plexus/plexus-archiver/1.0-alpha-11-SNAPSHOT/plexus-archiver-1.0-alpha-11-20081022.112233-1.jar

You could always specify a custom classpathLayoutType and customClasspathLayout configuration to modify this.

See MSHARED-32 for more info on the custom layout stuff.