Did you get an answer to your questions regarding the best way to fix this?

We're suffering the same problem and would like to find a fix :/

http://jira.codehaus.org/browse/MNG-775 might make fixing this the "right" way rather difficult

MNG-775 doesn't affect this because:

• if the artifact is released this bug does not occur
• if the artifact is not deployed (only installed) then the correct value is -SNAPSHOT

so the only time this problem occurrs is when the artifact is deployed but not yet released.
If the artifact is deployed it has been placed in a repository with a timestamped snapshot version (complete with build number) and hence MNG-775 does not apply.

My current work around is to manually rename the assembled artifacts to -SNAPSHOT.

The notes in MASSEMBLY-67 list the cause of the problem, the use of Project.getRuntimeClasspathElements() instead of using the runtime artifacts.

I'm looking into test cases now and should know more by the end of the week.

It also includes a cleanup of the unit tests, moving of the unit test data from src/test/resources into src/test/unit-test-data as this was causing the build to fail by trying to compile incomplete classes in src/test/resources.

Plus a cleanup of JarSignVerifyMojo to remove Eclipse problem markers

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

${artifactId}-${baseVersion}.${extension}

Using ${baseVersion} for cases where you want to preserve the -SNAPSHOT naming, the plugin retains the ability to use ${version} for the timestamp-buildnumber naming, which is useful for describing the exact library version included in the assembly.

(This issue can be closed)

It is true that outputFileNameMapping provides a workaround, but it is only a workaround, not a true fix.

I am investigating how to make the jar plugin add the actual timestamped name to the classpath.

<build>
  <finalName>gt-${artifactId}-${version}</finalName>

but the manifest classpath generated by Maven contains only ${artifactId}-${version}.jar entries, which are non-existent JARs.

Note: this problem happen only when the JAR dependencis come from the repository. The manifest classpath is correct if all dependencies were compiled in the same "mvn install" cycle.

1) Check out maven-archiver-2.2
Apply MNG-2456-maxb.patch
Deploy to local organization repository as (e.g.) 2.2-maxb-1
2) Check out maven-jar-plugin-2.1
Change maven-archiver dependency version in pom to 2.2-maxb-1
Deploy to local organization repository as (e.g.) 2.1-maxb-1
3) Reference maven-jar-plugin 2.1-maxb-1 in poms.

This is adequate when using maven-assembly-plugin 2.1. maven-assembly-plugin 2.2-beta-1 has broken things again though. (MASSEMBLY-211)