Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
3.6.1
-
None
-
None
Description
I apologize in advance for the vagueness.
In ArtifactUtils, there is a method named toSnapshotVersion(String).
I am using a project whose released version depends on a pinned snapshot: https://github.com/jbosstm/narayana/blob/a66d5bd3ebfa96ab7e4142f28960a99b941a30e7/rts/lra/pom.xml#L29
This works fine for things like unit tests and so on.
For various reasons, some of which are good and some of which are bad, we need to copy this pinned snapshot using the Maven dependency plugin's copy-dependencies goal. We construct a prefixed classpath entry in a jar file's manifest that refers to this pinned snapshot version.
When we do so, we discover that although this project depends on a pinned snapshot, and although the Maven shared archiver constructs the manifest Class-Path: entry properly, i.e. referring to the pinned version, not anything ending in -SNAPSHOT, the copy-dependencies goal seems to infer that the pinned version is in fact a snapshot version, and so when the jar file is copied it ends up with a suffix of -SNAPSHOT. The end result is that although the Class-Path: header is correct, no such pinned snapshot version jar file exists. Instead, a jar file with -SNAPSHOT as a suffix is there instead, and we get classloading errors.
I've traced the problem to ArtifactUtils where its toSnapshotVersion(String) method appears to recognize this pinned version string as a snapshot, and "helpfully" erases it, turning the resulting jar file back into a -SNAPSHOT suffixed jar file.
I don't see any workaround to this problem. Is there a reason for this helpful behavior?