[
https://issues.apache.org/jira/browse/MNG-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829293#comment-17829293
]
ASF GitHub Bot commented on MNG-8081:
-------------------------------------
gnodet commented on PR #1446:
URL: https://github.com/apache/maven/pull/1446#issuecomment-2010564585
> @mbenson well a mini language got rejected multiple times on the list -
this is where this sh solution comes from. ultimately I'm for having a
multipass filtering to filter as much as we can but my personal preference
would be to do it on the full model and not specifically for profiles. That
said, while v4 has the exact same code than v3.9 I'm happy.
It seems it can be solved really easily though:
https://github.com/kpiwko/el-profile-activator-extension/blob/master/src/main/java/com/redhat/jboss/maven/elprofile/ElProfileActivator.java
> default profile activation should consider available system and user
> properties
> -------------------------------------------------------------------------------
>
> Key: MNG-8081
> URL: https://issues.apache.org/jira/browse/MNG-8081
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
> Affects Versions: 3.9.6, 4.0.0
> Reporter: Matthew Jason Benson
> Priority: Minor
>
> As discussed in my open PR, my use case is to compare between environment
> variables e.g.:
> {code:java}
> <activation>
> <property>
> <name>env.FOO</name>
> <value>${env.BAR}</value>
> </property>
> </activation>{code}
> Limiting the interpolation to user/system properties means that there is no
> mindf*ck resulting from profile activation order, etc., and keeps this
> request nonthreatening.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
