While working on my TDD book, I played with Maven profiles to write the chapter.

If you use Maven profiles, you might want to use an activation strategy to enable the profile under certain circumstances automatically. There’s also a particular option, “<activeByDefault>”, which seems self-explanatory. This must mean that that profile will be constantly active by default unless you explicitly disable it, e.g., with “-P!profileid”.

Here’s a possible minimal example:

By using the maven-help-plugin‘s goal “active-profiles,” we can verify that:

Unfortunately, this will probably never work as we expect. For example, let’s add another profile (without any activation strategy in this example):

If we explicitly enable such a profile, we’d expect the previous one is still “active by default”, but we have a terrible surprise:

As it is documented (https://maven.apache.org/guides/introduction/introduction-to-profiles.html):

This profile will automatically be active for all builds unless another profile in the same POM is activated using one of the previously described methods. All profiles that are active by default are automatically deactivated when a profile in the POM is activated on the command line or through its activation config.

Counterintuitive, but it’s like that, like it or not.

However, the documentation also tells you how to achieve the “really active by default”; it’s a matter of activating the profile when a property is NOT defined. Let’s create another profile following this approach:

And verify that:

The profile we’ve just added will be activated when the system property “skipMe” is not defined. So, it’s really active by default unless you pass to the command line “-DskipMe”.

Note also that the “<activeByDefault>” property is really misleading. In fact, as long as another profile is automatically activated (i.e., not explicitly), the “<activeByDefault>” is useless. In fact, with the profile we’ve just active since it’s really active by default, it also disables, by default, “notReallyActiveByDefault”:

Let’s do some further experiments and add another profile, which is activated when the property “activateMe” is defined:

Let’s define the property on the command line, and we get the expected result:

We can also refine the activation:

If we define that property, the profile will be activated, and if we define that property with another value, it will not be activated (in any case, “reallyActiveByDefault” is still activated):

REMEMBER: You CANNOT activate that profile by defining a property in the POM, though:

If you want, you can temporarily switch the activation with a negated property, similar to what we’ve done before:

And verify the expected result:

That’s the complete example of POM:

However, please remember not to abuse profiles, or the build will easily become hard to maintain.