[ 
https://issues.apache.org/jira/browse/MNG-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909306#comment-16909306
 ] 

Laird Nelson commented on MNG-6735:
-----------------------------------

I'll let you guys figure it out or close this issue; I can get around this 
issue by using the {{useBaseVersion}} configuration parameter.  Thanks!

> 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)

Reply via email to