Laird Nelson created MNG-6735:

             Summary: ArtifactUtils#toSnapshotVersion problem with pinned 
                 Key: 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: 

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 

This message was sent by Atlassian JIRA

Reply via email to