|
|
|
[
Permlink
| « Hide
]
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.
Test Cases that exercise the problems.
(Unfortunately the patch also includes previous steps) Patch to fix the bug and get working unit test
(Unfortunately the patch also includes previous steps) Oops. Classpath is missing file extension...
Need to update tests and repatch. Patch adds the type of the artifact to the classpath which was incorrectly left off.
In
The solution here is to use an outputFileNameMapping such as this: ${artifactId}-${baseVersion}.${extension} 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.
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.
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:
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: In practice this seems to work, even if it is a little ugly. 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
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.
i got same problem. for the start i workarounded this by setting <uniqueVersion>false</uniqueVersion> in distribution management for snapshots.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||