[
https://issues.apache.org/jira/browse/MNG-8492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pawel Veselov updated MNG-8492:
-------------------------------
Description:
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:
{noformat}
[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)
...
{noformat}
But executing the build shows it's not:
{noformat}
[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:
{noformat}
Explicitly activating the profile "works":
{noformat}
[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:
{noformat}
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:
# 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.
# {{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:
{noformat}
[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)
{noformat}
was:
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:
{noformat}
[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)
...
{noformat}
But executing the build shows it's not:
{noformat}
[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:
{noformat}
Explicitly activating the profile "works":
{noformat}
[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:
{noformat}
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:
{noformat}
[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)
{noformat}
> Profile reported as activated in sub-module is not, in fact, active
> -------------------------------------------------------------------
>
> Key: MNG-8492
> URL: https://issues.apache.org/jira/browse/MNG-8492
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
> Affects Versions: 3.9.9
> Reporter: Pawel Veselov
> Priority: Major
>
> 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:
> {noformat}
> [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)
> ...
> {noformat}
> But executing the build shows it's not:
> {noformat}
> [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:
> {noformat}
> Explicitly activating the profile "works":
> {noformat}
> [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:
> {noformat}
> 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:
> # 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.
> # {{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:
> {noformat}
> [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)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
