[
https://issues.apache.org/jira/browse/MNG-6000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765549#comment-15765549
]
Joerg Schaible commented on MNG-6000:
-------------------------------------
This is already possible using file exists.
> activeProfiles in pom.xml
> -------------------------
>
> Key: MNG-6000
> URL: https://issues.apache.org/jira/browse/MNG-6000
> Project: Maven
> Issue Type: Improvement
> Components: POM, Profiles
> Reporter: Fabrizio Lungo
> Labels: features, maven
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
