Often you can observe that people are using profiles to activate/deactivate modules in a Maven build like the following or something similar:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
The question is: Why is this bad?
First let us reduce the above example to a simpler one like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
One of the important situations is if you like to create a release of your artifacts via the maven-release-plugin which is not really unusual (or shouldn’t be). What will happen if you do that with a pom like the above?
If you don’t activate the profile
supp during the release process
module-2 parents versions will be changed. But — the parent
version of the
module-add has not been changed, because it was not part of the reactor during
the release plugin run.
This will result into a situation like this:
1 2 3 4
On the first glance this will work and will do what you want until you activate the profile
than your build will fail or you will get strange error messages about missing artifacts.
That is caused by the
module-add version which is not the same as the other modules in the multi-module
build and so maven tries to solve the module-add with the above version from the local repository instead from
the reactor (in other words from the current build) which will lead to the described problems.
So the gist is simply do never use modules in profiles. A solution for the above example might be to use the profile within the module itself
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
This has the obviously advantage that the module is part of the reactor run and no problems can occur with the versions during usage of maven-release-plugin and other helpful plugins (for example versions-maven-plugin) etc.