[
https://issues.apache.org/jira/browse/MNG-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852340#comment-17852340
]
Michaël commented on MNG-8138:
------------------------------
clear, tnx for explaining, i did expect these limitations as Maven 3 is pretty
aged by now but i do agree on the separations applied here.
i'm perfectly happy with the current workarounds, tnx :)
> Maven internal state should not allow to become "broken"
> --------------------------------------------------------
>
> Key: MNG-8138
> URL: https://issues.apache.org/jira/browse/MNG-8138
> Project: Maven
> Issue Type: Bug
> Components: Core
> Reporter: Tamas Cservenak
> Priority: Major
>
> It seems by certain goal combinations we can make Maven Project instance
> state end up in "wrong" state. Example:
> * create a packaging=pom project
> * invoke jar:jar deploy:deploy
> This will result in following:
> * MavenProject has packaging=pom
> * but, jar:jar will create (an empty) JAR and make it "main artifact"
> basically making JAR as main artifact with ".pom" extension (following what
> packaging artifact handler tells)
> * deploy will happily deploy the jar as pom (as it is the only one artifact
> in project, but backing file is empty JAR, no "replacement" happens here)
> Multiple issues here:
> * Maven should "protect" MavenProject instance IMHO
> * jar:jar should not (or core should not allow) to "break the state"
> * m-deploy-p should figure out this situation: we deal with two artifacts
> (POM and "main JAR") but due packaging they end up on same URL?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
