Maven Shared Components

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

Details

  • Testcase included:
    yes
  • Number of attachments :
    5

Description

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.

Attachments

  1. Text File
    MNG-2456-maxb.patch
    11/Sep/06 10:26 AM
    6 kB
    Max Bowsher
  2. Text File
    MNG-2456-patch.txt
    06/Aug/06 7:13 PM
    25 kB
    Barrie Treloar
  3. Text File
    MNG-2456-step1-refactoring-patch.txt
    19/Jul/06 7:56 PM
    20 kB
    Barrie Treloar
  4. Text File
    MNG-2456-step2-add-test-cases-patch.txt
    19/Jul/06 9:07 PM
    25 kB
    Barrie Treloar
  5. Text File
    MNG-2456-step3-fix-bug-patch.txt
    19/Jul/06 9:15 PM
    25 kB
    Barrie Treloar

Issue Links

This issue relates to:
MDEPLOY-57 <uniqueVersion>false</uniqueVersion> not honored inside <profile> Critical Closed
MASSEMBLY-67 assembling dependent jars or snapshots uses timestamp formatted version instead of ${version} Major Closed
MJAR-28 Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions Major Closed
This issue is related to:
MDEPLOY-57 <uniqueVersion>false</uniqueVersion> not honored inside <profile> Critical Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Barrie Treloar added a comment -

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

Show
Barrie Treloar added a comment - Attached refactoring patch, with appropriate test cases, that changes Maven Archiver to use Project.getRuntimeArtifacts instead of Project.getRuntimeClasspathElements.
Hide
Permalink
Barrie Treloar added a comment -

Test Cases that exercise the problems.
(Unfortunately the patch also includes previous steps)

Show
Barrie Treloar added a comment - Test Cases that exercise the problems. (Unfortunately the patch also includes previous steps)
Hide
Permalink
Barrie Treloar added a comment -

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

Show
Barrie Treloar added a comment - Patch to fix the bug and get working unit test (Unfortunately the patch also includes previous steps)
Hide
Permalink
Barrie Treloar added a comment -

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

Show
Barrie Treloar added a comment - Oops. Classpath is missing file extension... Need to update tests and repatch.
Hide
Permalink
Barrie Treloar added a comment -

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

Show
Barrie Treloar added a comment - Patch adds the type of the artifact to the classpath which was incorrectly left off.
Hide
Permalink
Barrie Treloar added a comment -

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.

Show
Barrie Treloar added a comment - 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.
Hide
Permalink
Max Bowsher added a comment -

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.

Show
Max Bowsher added a comment - 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.
Hide
Permalink
Max Bowsher added a comment -

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.

Show
Max Bowsher added a comment - 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.
Hide
Permalink
Max Bowsher added a comment -

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.

Show
Max Bowsher added a comment - 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.
Hide
Permalink
Christian Goetze added a comment -

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

Show
Christian Goetze added a comment - 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"...
Hide
Permalink
Matthew McCullough added a comment - - 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.

Show
Matthew McCullough added a comment - - 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.
Hide
Permalink
Brian Fox added a comment -

Can someone produce an IT for this?

Show
Brian Fox added a comment - Can someone produce an IT for this?
Hide
Permalink
manuel aldana added a comment -

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

Show
manuel aldana added a comment - i got same problem. for the start i workarounded this by setting <uniqueVersion>false</uniqueVersion> in distribution management for snapshots.
Hide
Permalink
darbois tomas added a comment - - edited

Error

Show
darbois tomas added a comment - - edited Error
Hide
Permalink
John Casey added a comment - - edited

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.

Show
John Casey added a comment - - edited 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.

People

Vote (9)
Watch (10)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.