Are many legacy profiles of one plugin in Maven a good idea?

Question

In our infrastructure, we have many small Java projects built by Maven2. Each project has its own pom.xml, which is ultimately inherited from our parent parent company.

We recently started adding small profiles to the parent pom, which is disabled by default, which, when it is turned on, executes one plugin in the usual way.

Examples:

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

This is used to specify assemblies on our CI server, for example:

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

etc.

Until now, this, apparently, provided a convenient composition of additional functions.

However, are there any dangers or pitfalls in the continuation of this approach (obvious or not)? Could this type of functionality be better implemented or expressed in another way?

Answer 1

You are a little suspicious of this approach, but you are not quite sure why, after all, it is quite convenient. In any case, this is what I feel about this: I really do not know why, but it seems a little strange.

Consider two questions: a) what are the profiles for? b) What alternative approaches should we compare with your approach?

Regarding a), I think the profiles are for different build or runtime environments. You may depend on locally installed software, where you must use a profile to determine the path to the executable in the respective environments. Or you may have profiles for different runtime configurations, such as development, test, production. More information about this can be found at 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), the ideas that come to my mind:

• running plugins with command line properties. For example, mvn -Dfitnesse = true. As is well known, -DdownloadSources = true for the eclipse plugin, or -Dmaven.test.skip = true for certainty. But this requires the plugin to have a flag to run execution. Not all plugins you need can have this.
• Challenge goals explicitly. You can invoke multiple targets on the same command line, for example, "mvn clean package war: exploded". When fitness is performed automatically (using the appropriate profile), it means that its implementation is tied to the phase of the life cycle. That is, whenever this phase in the life cycle is reached, the plugin is executed. Instead of tying the execution of plugins to the stages of the life cycle, you should be able to include the plugin, but execute it only when explicitly called. Thus, your call will look like this: "mvn fitnesse: run source: jar deploy".

The answer to question a) may explain the "strangeness". This is simply not what profiles are for.

Therefore, I believe that alternative 2 could be better. The use of profiles can become problematic when "real" profiles for different execution or assembly conditions take effect. You will probably have a confusing mix of profiles where profiles mean very different things (for example, “test” means the environment, while “fitness” will mean the goal). If you just name the goals explicitly, I think it will be very clear and flexible. Remembering the names of the plugins / goals should not be harder if you remember the names of the profiles.

Answer 2

The problem with this solution is that you can create a “pick and choose” model that is slightly non-complete. In the case of the profiles you describe, you are a kind of intermediary; if each profile gives a decent result itself, you can be fine. The moment you begin to demand specific combinations of profiles, I think you are heading for trouble.

Individual developers typically encounter consistency issues because they forget which set of profiles should be used for this scenario. Your mileage may vary, but we had real problems with this. Half of your developers will forget the “right” combinations only after a short time and end up spending hours on a regular basis because they run the wrong combinations at the wrong time.

The practical problem that you will encounter is that AFAIK does not have the ability to have a set of “meta” profiles that activate a set of subprofiles. If there was a good way to create an umbrella profile, it would be really neat. Your suitability and source profiles must be truly private, activated by one or more meta profiles. (You can activate the default value set in settings.xml for each developer)

Answer 3

There are no problems with having multiple profiles in Maven, in fact, I think this is a great way to let your assembly enable and disable functionality classes. I would recommend calling them based on their function, not the plugin, and consider grouping functionally related plugins in one profile.

As a precedent for you, Maven super POM has a “release profile” that contains configurations for source, javadoc and deploy plugins.

You should consider the following approach, so your “fitness” profile will become an “integration test”, and you can choose additional plugins in this profile if you need it later. Similarly, a “clover” profile could be renamed “site”, and you could define additional reports in that profile, for example. configurations for JDepend, JXR, PMD plugins.