Maven 2.x JAR Plugin

This issue really comes into play when using the assembly plugin as the assembly plugin bundles the jar in the artifactID-X.X-YYYYMMDD-HHmmss-V.jar form.

yep, the manifest should contain the actual file name (ie, timestamped)

Woops, I've attached the comments to bug MASSEMBLY-67.
Never mind, they are related.
Request for advice sent to dev list, see http://www.nabble.com/MJAR-28-Advice-from-dev%3A-Mainfest.mf-Class-Path-entries-by-MavenArchiver%2C-Assembly-and-Jar-tf1908862.html

Baerrach, have you been able to make any progress on this?

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

Most of the comments I have made have been against MASSEMBLY-67 but the bug I believe is definitely in Maven Archiver (no bug has yet been raised for it)

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.

This patch includes the changes needed to support MNG-2456 and an update of the documentation to include reference to user specified classpath inclusions.

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

In MASSEMBLY-67 John Casey says

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)

I do not agree that this issue should 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.

The patch I provided does just that, for SNAPSHOTS it uses the timestamped version instead of -SNAPSHOT.

Baerrach: Do you mean MJAR-28-patch.txt ? If so, I don't see how it can do that, since it seems mostly to be a tree reorganization and deletion of dead comments and code. Is it possible that the wrong file is attached to JIRA ?

Sorry you are right.
The changes I needed to make for this are in maven-archiver in the linked issue MNG-2456 as the archiver does all the actual work, jar just invokes archiver.

Perhaps this issue should be closed, then, if the problem is located entirely within maven-archiver, and the patch attached here does not relate to the problem described?

Maybe related to this issue: the manifest classpath generated by Maven ignores the "real" JAR name as specified in <finalName>>. For example the Geotools project tried the following configuration:

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

I'm also experiencing this. We're working on a huge project with about 15 sub projects. This really causes problems with our deployable artifacts. Is there anyone working on it? If not, where would I begin looking to fix this?

Todd: The local workaround that I'm using consists of:

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)

This issue may be related to the logic affected by MSHARED-32.

Updated to use latest Maven-Archiver (2.4-SNAPSHOT) which fixes this issue. See MSHARED-32 and MSHARED-36, plus the doco for useUniqueVersions configuration flag (default is true) for manifest configurations, new for maven-archiver-2.4-snapshot.

Currently the Fix Version for this issue is None. In what release is it likely to appear?

Any progress on this? I'm still having the issue with latest available versions of maven (2.2.1) and of all plugins...

Looks like this is fixed in trunk, so I'm updating the fix version to the next scheduled release.