[MNG-8138] Maven internal state should not allow to become "broken"

**[Tamas Cservenak](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=cstamas)** opened **[MNG-8138](https://issues.apache.org/jira/browse/MNG-8138?redirect=false)** and commented

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?

---

**Issue Links:**
- [MINSTALL-201](https://issues.apache.org/jira/browse/MINSTALL-201) Regression in 3.1.2 when installing pom artifact
(_**"causes"**_)
- [MINSTALL-200](https://issues.apache.org/jira/browse/MINSTALL-200) "mvn jar:jar install:install" installs a jar instead of a pom
(_**"causes"**_)
- [MDEPLOY-318](https://issues.apache.org/jira/browse/MDEPLOY-318) version 3.1.2 is uploading jar files to wrong endpoints

0 votes, 5 watchers

Reproduce the reported packaging=pom case with jar:jar deploy:deploy and inspect MavenProject state alongside the related MINSTALL-200, MINSTALL-201, and MDEPLOY-318 reports. Determine which component owns the inconsistent artifact handling; done means the project state and deployed artifact remain correct for this goal combination.

Written by the indexing model from the issue text.