[
https://issues.apache.org/jira/browse/MJAR-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16744498#comment-16744498
]
Archie Cobbs commented on MJAR-254:
-----------------------------------
I guess I was not getting what {{<finalName>}} was for.
Apparently I'm not alone: [this
thread|http://maven.40175.n5.nabble.com/What-is-the-purpose-of-lt-finalName-gt-really-td113492.html]
pretty well captures the confusion out there.
So dumb question I have is: why is it necessary for the install/deploy process
change the name back from finalName to artifactId, overriding my explicit
instructions?
Shouldn't it deploy {{generated-sources.jar}} as
{{generated-version-sources.jar}} instead of {{artifactId-version-sources.jar}}?
The only apparent answer is: "Because then a future Maven client would not be
able to find it in the repository".
But isn't that my problem to worry about? I.e., how I'm going to use my
repository is ultimately my business.
Have {{mvn deploy}} issue a warning - fine - but don't stop me from doing
something reasonable due to a lack of imagination.
Apologies if I'm missing something obvious, I'm not a Maven expert.
Thanks.
> The fix for MJAR-198 is incomplete: filename conflict not detected
> ------------------------------------------------------------------
>
> Key: MJAR-254
> URL: https://issues.apache.org/jira/browse/MJAR-254
> Project: Maven JAR Plugin
> Issue Type: Bug
> Affects Versions: 3.0.0
> Reporter: Archie Cobbs
> Priority: Minor
> Labels: up-for-grabs
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See this comment on MJAR-198.
> In summary, the build should fail if the actual JAR file would get
> overridden, not if the classifier happens to be the same. That is, the
> conflict is at the actual filesystem level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
