[
https://issues.apache.org/jira/browse/MNG-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829347#comment-17829347
]
ASF GitHub Bot commented on MNG-8081:
-------------------------------------
mbenson commented on PR #1446:
URL: https://github.com/apache/maven/pull/1446#issuecomment-2011019881
> > That was what I originally considered, but I quickly came to the opinion
that as soon as we did it that way, someone would want to use some such
property to match a Java version, etc., and that this would be a generally
applicable way to solve a broad cross section of similar use cases.
>
> How could that (solving similar use cases) be considered a bad thing ?
That's what I wanted to know 😮
i.e., I think this approach takes care of them in one place before everybody
comes asking for similar changes to be made everywhere.
> 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)
