Question

In our infrastructure, we have lots of little Java projects built by Maven2. Each project has its own pom.xml that ultimately inherits from our one company ‘master’ parent pom.

We’ve recently started adding small profiles to our parent pom, disabled by default, that, when enabled, execute a single plugin in a conventional manner.

Examples:

• The ‘sources‘ profile executes the maven-source-plugin to create the jar of project sources.
• The ‘clover‘ profile executes the maven-clover2-plugin to generate the Clover report. It also embeds our Clover license file so it need not be re-specified in child projects.
• The ‘fitnesse‘ profile executes the fitnesse-maven-plugin to run the fitnesse tests associated with the project. It contains the fitnesse server host and port and other information that need not be repeated.

This is being used to specify builds in our CI server like:

mvn test -P clover mvn deploy site-deploy -P fitnesse,sources 

and so on.

So far, this seems to provide a convenient composition of optional features.

However, are there any dangers or pitfalls in continuing on with this approach (obvious or otherwise)? Could this type of functionality be better implemented or expressed in another way?

Answer 1

You seem slightly suspicious towards that approach, but you’re not really sure why – after all, it is quite convenient. Anyway, that’s what I feel about it: I don’t really know why, but it seems somewhat odd.

Let’s consider these two questions: a) what are profiles meant for? b) what are the alternative approaches we should should compare your approach with?

Regarding a), I think profiles are meant for different build or execution environments. You may depend on locally installed software, where you would use a profile to define the path to the executable in the respective environments. Or you may have profiles for different runtime configurations, such as ‘development’, ‘test’, ‘production’. More about this is found on http://maven.apache.org/guides/mini/guide-building-for-different-environments.html and http://maven.apache.org/guides/introduction/introduction-to-profiles.html.

As for b), ideas that come to my head:

1. triggering the plug-ins with command line properties. Such as mvn -Dfitnesse=true deploy. Like the well known -DdownloadSources=true for the eclipse plugin, or -Dmaven.test.skip=true for surefire. But that would require the plugin to have a flag to trigger the execution. Not all the plug-ins you need might have that.
2. Calling the goals explicitly. You can call several goals on one command line, like ‘mvn clean package war:exploded’. When fitnesse is executed automatically (using the respective profile), it means its execution is bound to a lifecycle phase. That is, whenever that phase in the lifecycle is reached, the plugin is executed. Rather than binding plugin executions to lifecycle phases, you should be able to include the plugin, but only execute it when it is called explicitly. So your call would look like ‘mvn fitnesse:run source:jar deploy’.

The answer to question a) might explain the ‘oddness’. It is just not what profiles are meant for.

Therefore, I think alternative 2 could actually be a better approach. Using profiles might become problematic when ‘real’ profiles for different execution or build environments come into play. You would end up with a possibly confusing mixture of profiles, where profiles mean very different things (e.g. ‘test’ would denote an environment while ‘fitnesse’ would denote a goal). If you would just call the goals explicitly, I think that would be very clear and flexible. Remembering the plugin/goal names should not be more difficult that remembering the profile names.