maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joerg Schaible (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MNG-6000) activeProfiles in pom.xml
Date Tue, 20 Dec 2016 23:23:58 GMT

    [ 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)

Mime
View raw message