John Casey wrote:
The activeByDefault flag was originally designed to allow profiles to
work as a group, with a default selection. Obviously, it's an incomplete
design, since it doesn't allow for profiles that _aren't_ part of that
grouping to be activated/deactivated independently. As for the default
profiles remaining active until deactivated, I think this would be the
most intuitive behavior, though I'd still really like to see profile
groups where there can be a default "selection" that is active unless
another profile in that group is activated. Also, in the past there has
been some quirks with the deactivation flag, that seemed to keep it from
working (at least in some cases). No, I don't have specifics, but I can
remember it coming up before. :) I think if we straighten out the
notation for activating/deactivating, then make sure it works on all
platforms (it may have been something about commons-cli snagging on a
leading '-' for the deactivation of a single profile), we should make
defaults stay active until deactivated. Later, if we find a good
mechanism for the profile grouping I was originally striving for, we can
implement it in 2.2+ or something.
I think that if we add the possibility of a deactivation configuration
(MNG-3326) similar to the current activation config we could accomplish the same
thing as profile groups and the logic to implement it might be a bit simpler.
So for example, you could define a few profiles like this:
<profiles>
<profile>
<id>group1-profile1</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<deactivation>
<property>
<name>group1-profile2.on</name>
<value>true</value>
</property>
</deactivation>
</profile>
<profile>
<id>group1-profile2</id>
<activation>
<property>
<name>group1-profile2.on</name>
<value>true</value>
</property>
</activation>
</profile>
<profile>
<id>group2-profile3</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
...
</profiles>
So in this example, you could use "mvn -Dgroup1.profile2.on=true" and that would
activate group1.profile2, but deactivate group1.profile1. If you combine this
type of deactivation with being able to specify any of the activation or
deactivation conditions for multiple values, the user would have a lot of
flexibility to set things up however they want.
And the logic for implementing it could basically be check the activation
conditions to see if any of them activate the given profile, then check the
deactivations for the active profiles to see if any of them should be deactivated.
As for the E: and D: prefixes, this is something I threw in the other
day to see if it would improve things. I wasn't sure whether it was a
good idea or not, but it's easy enough to take out since nothing has
been released. Also, I think having '!' in there is a good idea, even
though +/- are already in use. What's the harm in adding more than one
way of doing this?
-john
On May 14, 2008, at 5:17 PM, Paul Gier wrote:
I would like to bring up a couple of issues related to profile
activation and deactivation. While working on MNG-3545 I noticed some
cases where the current behaviour might be improved.
1. What is the correct behaviour when there is more than one
activeByDefault profile and I manually activate one of them?
Currently, if I have two activeByDefault profiles, profile1 and
profile2, and I run "mvn -P+profile1" then profile1 stays active and
profile2 is deactivated. This also bring up the following more
general question.
2. Should default profiles be automatically deactivated if another
profile is activated? I don't think the current behaviour should be
changed in 2.0.x, but for 2.1 I think it's worth considering leaving
default profiles active unless explicitly disabled.
If you think of profiles as being mutually exclusive, then it makes
sense to activate one and have the default profile be deactivated.
But IMO that seems to be a less common use case vs. using profiles to
activate particular parts of a build and not normally interfering with
each other. In this case it seems more intuitive that an
activeByDefault profile is always active unless deactivated. In
addition, now that profiles can be deactivated as needed from the
command line, there doesn't seem to be as much of a need to have
activeByDefault profiles automatically turn off.
3. There was a suggestion to allow the use of "!" to disable a
profile. So the command line would look like: mvn -P!myProfile
This seems more intuitive than the current syntax using a dash, and I
created MNG-3571 for it. But I'm hesitant to add it since we can
already use "-" for this, and it looks like "mvn -P D:myProfile" was
added as another option for disabling a profile in 2.1.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
