[MJAR-28] Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0
• Fix Version/s: 2.3
• Assignee: John Dennis Casey
• Reporter: Mark J. Titorenko
• Created: 08/Feb/06 08:39
• Updated: 06/Apr/15 01:16
• Resolved: 22/Sep/08 15:46

Description

When the POM contains dependencies to snapshot versions of jars, and snapshot versions of those jars are downloaded from a remote repository, the name of the jar contained in the classpath added to the manifest, of the form artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar downloaded, which contains version information of the form artifactID-X.X-YYYYMMDD.HHmmss-V.jar.

This does not affect snapshot versions which have been directly installed into a local repository and have no uploaded version within the remote repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar form.

Issue Links

• is related to: MASSEMBLY-211 assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names
• is related to: MSHARED-36 Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
• is related to: MSHARED-32 Customization of jar-name pattern of classpath-entries inside MANIFEST.MF
• relates to: MDEPLOY-57 <uniqueVersion>false</uniqueVersion> not honored inside <profile>
• relates to: MASSEMBLY-67 assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}