History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: MSHARED-36
Type: Bug Bug
Status: Reopened Reopened
Priority: Major Major
Assignee: Kenney Westerhof
Reporter: Barrie Treloar
Votes: 9
Watchers: 11
Operations

If you were logged in you would be able to see more operations.
Maven Shared Components

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

Created: 19/Jul/06 07:53 PM   Updated: 12/Jun/08 07:13 PM
Component/s: maven-archiver
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. Text File MNG-2456-maxb.patch (6 kb)
2. Text File MNG-2456-patch.txt (25 kb)
3. Text File MNG-2456-step1-refactoring-patch.txt (20 kb)
4. Text File MNG-2456-step2-add-test-cases-patch.txt (25 kb)
5. Text File MNG-2456-step3-fix-bug-patch.txt (25 kb)

Issue Links:
Related

Testcase included: yes


 Description  « Hide
See related problems MJAR-28 and MASSEMBLY-67.

Summary:

The Maven-Archiver uses the file part of the artifact's filename to create the Class-Path entries in the Manifest.
This works fine for released artifacts and non-deployed snapshot.
The problem occurs when using a deployed snapshot as the assembly plugin will copy the dependency as ${artifactId}-${version}-timestampedversion.jar and the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
thus use of java -jar <jarfile> will fail because of the differing names.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Barrie Treloar - 19/Jul/06 07:56 PM
Attached refactoring patch, with appropriate test cases, that changes Maven Archiver to use Project.getRuntimeArtifacts instead of Project.getRuntimeClasspathElements.

Barrie Treloar - 19/Jul/06 09:07 PM
Test Cases that exercise the problems.
(Unfortunately the patch also includes previous steps)

Barrie Treloar - 19/Jul/06 09:15 PM
Patch to fix the bug and get working unit test
(Unfortunately the patch also includes previous steps)

Barrie Treloar - 06/Aug/06 06:51 PM
Oops. Classpath is missing file extension...
Need to update tests and repatch.

Barrie Treloar - 06/Aug/06 07:13 PM
Patch adds the type of the artifact to the classpath which was incorrectly left off.

Barrie Treloar - 11/Aug/06 04:19 PM
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.


Max Bowsher - 06/Sep/06 02:13 PM
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.

Max Bowsher - 11/Sep/06 10:17 AM
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.

Max Bowsher - 11/Sep/06 10:26 AM
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.


Christian Goetze - 12/Jan/07 12:02 PM
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"...

Matthew McCullough - 15/Aug/07 06:23 PM - edited
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.

Brian Fox - 07/Mar/08 07:45 PM
Can someone produce an IT for this?

manuel aldana - 14/May/08 04:15 AM
i got same problem. for the start i workarounded this by setting <uniqueVersion>false</uniqueVersion> in distribution management for snapshots.

darbois tomas - 28/May/08 09:38 AM - edited
Error