[ https://issues.apache.org/jira/browse/MNG-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853539#comment-17853539 ]
Slawomir Jaranowski commented on MNG-8138: ------------------------------------------ The same will be eg with: {code} mvn -N ejb:ejb install:install {code} so checking in packaging plugin looks not a like the best place - we must do it in all packaging plugins ... > 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)