You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Michael Osipov (Jira)" <ji...@apache.org> on 2020/10/17 21:32:00 UTC
[jira] [Commented] (MNG-6735) ArtifactUtils#toSnapshotVersion
problem with pinned snapshots
[ https://issues.apache.org/jira/browse/MNG-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17216050#comment-17216050 ]
Michael Osipov commented on MNG-6735:
-------------------------------------
[~ljnelson], can you assemble a sample project depicting the problem? Moreover, as you seem have to debugged it. Where exactly (file) did you trace this down?
> 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
(v8.3.4#803005)