[MNG-6000] activeProfiles in pom.xml

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Won't Do
• Component/s: POM, Profiles
• Labels: features maven
• Assignee: Unassigned
• Reporter: Fabrizio Lungo
• Created: 14/Apr/16 15:26
• Updated: 22/Dec/19 13:35
• Resolved: 22/Dec/19 13:35

Description

I would like to see the ability to define <activeProfiles> in a pom. I think this would be extremely useful and provide a way for a parent pom to provide a set of profiles that can be picked and chosen from as per the needs of the project.

A simple but specific example is where I would like to have a profile from our corporate parent pom that is activated when a project should build an executable jar. This profile provides the configuration for the maven-jar-plugin (as well as adding some validations and checks) and we would like to activate this on a per project level.

Initially I tried using properties but activation conditions only look at system properties (and not pom defined ones) and even using a property in the <activateByDefault> tag. As described in MNG-5235 this is because profiles need to be processed first and using properties from the pom would create chicken-egg problems and inconsistencies because a profile can then modify these properties.

If <activeProfiles> were to be added to pom, this could be read first to determine if any profiles need to be activated and allow a pom to define which profiles will be active by default.

Two optional features that could be implemented to supplement this would be:

• Support for <activeProfiles> inside of a profile for profiles to be able to recursively enable other profiles (that they may depend on). This would allow reduction of duplication if two profiles require some shared preconditions they can then just activate the profile with this shared configuration and if one or both are activated, the shared configuration profile will be activated too. This should be fairly easy to implement using recursive checks and not revisiting any profiles already in an active list (to avoid cycles - which should be warned about - and unnecessary re-evaluations)
• Support for disabling profiles (possibly by using <profile>!profile-1</profile> syntax. This could have advantages where a parent pom activates a profile by default and the child wants it disabled by default although I can see this may cause problems.