[MNG-8492] Profile reported as activated in sub-module is not, in fact, active

**[Pawel Veselov](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=pveselov)** opened **[MNG-8492](https://issues.apache.org/jira/browse/MNG-8492?redirect=false)** and commented

Playground: https://github.com/veselov/maven-profile-test

There is a parent module and a sub-module.
Parent module "defines" a profile, and specifies its activation criteria (active by default).
Sub-module has a profile statement without activation criteria.
Now, the complexities of profile inheritance notwithstanding, the problem is that `help:active-profiles` disagrees with the actual active profiles.

I always run maven from the parent module.

Running `help:active-profiles` leads me to believe that the profile is "active" in the sub-module:

```
[vps@druid]~/tmp/multi-p$ mvn help:active-profiles
...
Active Profiles for Project 'org.vps:sub:jar:1.0-SNAPSHOT':

The following profiles are active:

- allow-snapshots (source: external)
- my-profile (source: org.vps:main:1.0-SNAPSHOT)
...
```

But executing the build shows it's not:

```
[vps@druid]~/tmp/multi-p$ mvn package
...
[INFO] --- jar:3.3.0:jar (default-jar) @ sub ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for main 1.0-SNAPSHOT:
```

Explicitly activating the profile "works":

```
[vps@druid]~/tmp/multi-p$ mvn -Pmy-profile package
...
[INFO] --- jar:3.3.0:jar (default-jar) @ sub ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO]
[INFO] --- echo:1.2.0:echo (default) @ sub ---
[INFO] PLUGIN ACTIVE
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for main 1.0-SNAPSHOT:
```

Now, I'd imagine the answer to "why isn't the profile active when the sub-module is being built?" is - because that's how it's supposed to be, even though having to copy activation instructions in all sub-modules, for all involved profiles, is a serious nuisance. But at least then `help:active-profiles` and `help:all-profiles` should be of better help.

Things are generally confusing:
* `mvn -Pmy-profile help:active-profiles`
lists `my-profile` twice for the sub-module, active through parent, and through self.
* Adding `-pl sub` for `help:active-profiles`, regardless of `-Pmy-profile`
Produces the exact same output for the sub-module
* `mvn -pl sub help:all-profiles`
lists `my-profile` once for the sub-module, as active
* `mvn -pl sub -Pmy-profile help:all-profiles`
also lists `my-profile` once, as active (so no duplicate entries for that ID)

As to how to improve this:

1. I wish something can be done about `help:active-profiles` that would help. I've been racking my brain silly, and can't really come up with a more reasonable suggestion than to also list profiles that were left inactive (defies the purpose), or at least state that activation is "local to the source", to attract attention to the fact that if a profile with the same ID was used, it's not actually activated.
2. `help all-profiles` should definitely list profiles as many times as its encountered for cases when a child pom drags in parent pom's profile, and also indicate the parentage: i.e., in this case it could be:

```
[vps@druid]~/tmp/multi-p$ mvn help:all-profiles
...
Listing Profiles for Project: org.vps:sub:jar:1.0-SNAPSHOT
Profile Id: allow-snapshots (Active: true, Source: settings.xml)
Profile Id: my-profile (Active: true, Source: pom, inherited from org.vps:main:pom:1.0-SNAPSHOT)
Profile Id: my-profile (Active: false, Source: pom, direct)
```

---

**Affects:** 3.9.9

1 votes, 2 watchers

Reproduce the parent/sub-module case using the linked maven-profile-test playground, comparing `mvn help:active-profiles`, `help:all-profiles`, and `package` with and without `-Pmy-profile`. Trace the help goals' profile reporting entry points and define done as making their reported activation and inheritance agree with the build behavior, or clearly explaining the distinction.

Written by the indexing model from the issue text.