[
https://issues.apache.org/jira/browse/MNG-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8292:
---------------------------------
Description:
Profile activation needs to be reworked.
I propose to deprecate the full {{<activation>}} element and replace it with a
single {{<activation> ... </activation>}} element which would contain an
expression as described in MNG-8286. The only missing bit is the
{{activeByDefault}} feature which may need a few additional functions such as
{{active(profile-id)}} and {{{}inactive(profile-id){}}}.
A few points to keep in mind:
* project properties are used in a non coherent way now, this needs to be
cleaned up. There are use cases to leverage those properties during profile
activation, but we need to ensure that the early activated profile (computed on
the file model to get the list of subprojects) are stable. One way would be to
make sure that the list of subprojects does not change between the activated
file model and the effective model, either by checking that the resulting lists
are the same, or by actually doing it in two steps: a first activation would
inject the subprojects into the file model and a later step would compute the
effective model, ignoring the subprojects
* ultimately, the profile activation interpolation step should go away, as
properties can be interpolated on the fly during the expression evaluation (and
I would not go into interpreting the value of a property as an expression
recursively)
* for cascading profiles, my initial idea was that a profile can never be
deactivated once activated. So to compute the list of profiles, you start from
a complete list, find out which ones are activated, remove them from the list
and incorporate the properties into the context, and loop. This ensures we
can't run into infinite loops where a profile is activated, then deactivate...,
then activated, etc...
was:
Profile activation needs to be reworked.
I propose to deprecate the full {{<activation>}} element and replace it with a
single \{{<activation> ... </activation>}} element which would contain an
expression as described in MNG-8286. The only missing bit is the
\{{activeByDefault}} feature which may need a few additional functions such as
\{{active(profile-id)}} and \{{inactive(profile-id)}}.
> Rework profile activation
> -------------------------
>
> Key: MNG-8292
> URL: https://issues.apache.org/jira/browse/MNG-8292
> Project: Maven
> Issue Type: Task
> Components: Profiles
> Reporter: Guillaume Nodet
> Priority: Major
> Fix For: 4.1.0
>
>
> Profile activation needs to be reworked.
> I propose to deprecate the full {{<activation>}} element and replace it with
> a single {{<activation> ... </activation>}} element which would contain an
> expression as described in MNG-8286. The only missing bit is the
> {{activeByDefault}} feature which may need a few additional functions such as
> {{active(profile-id)}} and {{{}inactive(profile-id){}}}.
> A few points to keep in mind:
> * project properties are used in a non coherent way now, this needs to be
> cleaned up. There are use cases to leverage those properties during profile
> activation, but we need to ensure that the early activated profile (computed
> on the file model to get the list of subprojects) are stable. One way would
> be to make sure that the list of subprojects does not change between the
> activated file model and the effective model, either by checking that the
> resulting lists are the same, or by actually doing it in two steps: a first
> activation would inject the subprojects into the file model and a later step
> would compute the effective model, ignoring the subprojects
> * ultimately, the profile activation interpolation step should go away, as
> properties can be interpolated on the fly during the expression evaluation
> (and I would not go into interpreting the value of a property as an
> expression recursively)
> * for cascading profiles, my initial idea was that a profile can never be
> deactivated once activated. So to compute the list of profiles, you start
> from a complete list, find out which ones are activated, remove them from the
> list and incorporate the properties into the context, and loop. This ensures
> we can't run into infinite loops where a profile is activated, then
> deactivate..., then activated, etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
