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...
Attachments
Issue Links
- incorporates
-
MNG-4917 Profile not active even though it has activeByDefault set to true
-
- Reopened
-
1.
|
Add a condition profile based on a simple expressions |
|
Closed | Guillaume Nodet |
2.
|
Cascading profile activation |
|
In Progress | Guillaume Nodet |