[
https://issues.apache.org/jira/browse/MNG-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908723#comment-16908723
]
Michael Osipov commented on MNG-6735:
-------------------------------------
First of all, why do you rely on snapshots? The general concept of snapshot
versions are that you can replace one with each other with the same base
version where as release cannot. Regardless of this, it maybe by design what
you observe or just a subtile bug.
> 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
> Priority: Major
>
> 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)
