Let the order of profiles in `mvn -P...` determine their order in effective POM

This idea was suggested when discussing MNGSITE-124.

Currently, the resulting order is:

1. settings.xml - Auto-activated profiles (<activation/>), reverse definition order
2. settings.xml - CLI activated profiles, reverse definition order
3. pom.xml repos
4. parent pom repos

And adding auto-activated profile to -P does not change the result.

What is the actual use case or motivation for this request? It seems rather dangerous to make builds dependent on something like the CLI param order as this adds further variation between developers and threatens the idea of reproducible builds more.

Hi Benjamin,

The use case is any case when the user needs to have the profiles precedence under control.

Since Maven builds customization is based on merging one POM into other, the user should be able to specify the order in which this operation happens for the same-level "entities", e.g. two profiles in settings.xml.

Do you really think that CLI param order is something unstable? Usually the builds are run from some CI tool or at least a script, anyway.
Plus, this would apply only when the profiles actually overlap. In that case, it's most probably intentional, and it's their author's responsibility to document the proper order in which they are to be applied.

The use case is any case when the user needs to have the profiles precedence under control.

I fail to see how this answers my question for a practical usage scenario that would require this.

[..] the user should be able to specify the order in which this operation happens for the same-level "entities", e.g. two profiles in settings.xml.

Which he can be adjusting their declaration order in the settings or POM.

Do you really think that CLI param order is something unstable?

Whether documented or not, it's defacto behavior that "-Pfoo,bar" and "-Pbar,foo" yield the same effective POM. So users are not used to pay attention to the profile order on the CLI.

Plus, this would apply only when the profiles actually overlap.

What are overlapping profiles? For instance, two profiles could configure two different plugins (no overlap), bound to the same phase. What you suggest would effect the order of plugin executions, likely breaking builds.

> Which he can be adjusting their declaration order in the settings or POM.

That's my point - changing settings.xml everytime you need to change your build is not much user-friendly,
and when you need to do int programatically, it's kind of annoying.

And even when defining in XML, you can not set the order in all cases:
if some of the profiles are auto-activated. Those go first, no matter what.

One real use case:
settings.xml with two profiles, 1) profA, auto-activated, 2) profB, activated by -P profB.
They contain different repository definition.
I need Maven to query profB's repository first, but there's no way because Maven ignores the order of -P.
If this improvement was implemented, I could do "mvn install -PprofB,profA", and voi-la - Maven would do what I need.

Ok how about limiting this effect only to the repositories?

What could the possible motivation be for putting the repositories in REVERSE order of precedence, and putting the parent and global settings ahead of the local project settings? That is so counter-intuitive, one of the reasons why people complain about maven so much. I've spent many hours wondering what whim causes it to overwrite newer snapshot artifacts with older versions. In my case I have a staging repository activated by profile, with newer versions of the snapshot artifacts already in our public repository, but the local maven user gets the public snapshots even when the staging profile is activated. An intuitive ordering of the repositories search order for updates would be (from most local to least local, and overriding to manual to automatic profile activation):
1. Command line repository activation order (manually activated profiles overriding configured values)
2. Manually activated profiles
3. Automatically activated profiles
4. Local project profile(s) - manually activated
5. Local project defaults
6. Parent project profile(s)- manually activated
7. Parent project default
8. Global settings.xml profile(s) - manually activated
9. Global settings.xml defaults