Apply properties from profiles that are active by default

[erwint]

When using continuous delivery friendly version numbers with variables,
such variables can be either set externally (-D...) or via a profile
property. While the former works, the later does not. To fix this
properties from profiles that are active by default are now merged into
the effective model.

[cboehme]

I think, the properties from the model need to be added to merged properties before the properties from the profile. Properties defined in a profile overwrite the ones in the model.

[hohwille]

Sorry, for the late response - I was totally under water with lots of other OSS and closed projects. Thanks for your PR.
First of all I want to give a short explanation about profiles and flatten-maven-plugin. The idea of this plugin was to create a POM for deployment (mvn install and esp. mvn deploy) that is both minified (aka flattened) but also stable what means your output should not depend on your current environment so a deployment would result in a different POM depending on your OS, env variables, etc.

So far from the theory. In practice you of course can already inject variables via system properties as you pointed out. In the end we can not prevent a user from doing something wrong here.

However, what IMHO should be is that profiles are not triggered by default and this also implies profiles active by default. Why is that? There are tons of maven projects out there that use default profiles for local environment as simplification and use profile triggers to disable them in CI or for deployment builds.
This is why we use properties to activate profile specific behavior in this plugin. So far we only have this one:
http://www.mojohaus.org/flatten-maven-plugin/flatten-mojo.html#embedBuildProfileDependencies

My suggestion would therefore be to add a new property to flatten mojo that is false by default and if activated will trigger the feature that you implemented here. This would also guarantee compatibility when we bring this out in an upcoming version of this plugin (to have reproducible builds even if plugin versions are not specified and upgrading the plugin does not break the behavior in a way where only downgrading brings back the old behavior).

Do you see my point and agree? Would you even be willing to update your fork and this PR accordingly?
Thank you so much for taking care.

[haisum]

was this feature implemented somewhere else?

[hohwille]

Not AFAIK. I fear that we create a feature that will cause releases to contain POMs with passwords from settings.xml accidentally.