Laird Nelson created MNG-6735:
---------------------------------
Summary: ArtifactUtils#toSnapshotVersion problem with pinned
snapshots
Key: MNG-6735
URL: https://issues.apache.org/jira/browse/MNG-6735
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.6.1
Reporter: Laird Nelson
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?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
