Re: Profile Activation
The behavior is AND. You can have multiple profiles for OR. Chas > On Aug 15, 2016, at 11:45 AM, Christopher wrote: > > If there could be "AND" and "OR" primitives for profile activation > conditions, you could do something like: > > > > !profilea > > > profilea > !true > > > > Sadly, this feature does not exist. > >> On Fri, Aug 12, 2016, 11:45 Karl Heinz Marbaise wrote: >> >> Hi to all, >> >> I have the following profile: >> >> >> >> profile-not-value-true >> >> >> profilea >> !true >> >> >> >> >> >> com.soebes.maven.plugins >> echo-maven-plugin >> >> >> initialize >> >> echo >> >> >> >> >> >> profile not value true >> >> >> >> >> >> >> >> So the question is: What would you expect you need to do to activate >> this profile? >> >> Currently this profile is activated cause if I don't define the property >> "profilea" at all it seemed to that Maven is assuming this means "not >> value 'true'" ? >> >> I have assumed it should be activated if the property exists which means >> giving it on command line like this: >> >> mvn -Dprofilea >> >> >> >> WDYT ? >> >> Kind regards >> Karl Heinz Marbaise >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Profile Activation
If there could be "AND" and "OR" primitives for profile activation conditions, you could do something like: !profilea profilea !true Sadly, this feature does not exist. On Fri, Aug 12, 2016, 11:45 Karl Heinz Marbaise wrote: > Hi to all, > > I have the following profile: > > > >profile-not-value-true > > >profilea >!true > > > > > > com.soebes.maven.plugins > echo-maven-plugin > > > initialize > >echo > > > > > > profile not value true > > > > > > > > So the question is: What would you expect you need to do to activate > this profile? > > Currently this profile is activated cause if I don't define the property > "profilea" at all it seemed to that Maven is assuming this means "not > value 'true'" ? > > I have assumed it should be activated if the property exists which means > giving it on command line like this: > > mvn -Dprofilea > > > > WDYT ? > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Profile Activation
Hi, I could also reverse the question: how can I have an active profile by default, which should not be activated when skipITs is set to true. I don't think there's another solution than the current one. The fact that skipITs is treated as a boolean makes this example always work and there's no discussion. Confusion starts because the property can have more than 2 values. It all depends on the definition. For me it makes perfectly sense that 'mvn package -Denvironment=prod' and 'mvn package', since it fits with "always active unless environment is production". AFAIK the current logic has been there since the early versions of Maven, so I consider it as "works as designed". The funny thing is that we say you cannot program within the pom, but this not-expression is the only with some logic and not it seems it is causing trouble. Robert On Fri, 12 Aug 2016 21:18:06 +0200, Karl Heinz Marbaise wrote: Hi, First I have added the documentation about the opportunities like this (and other one as well a few days before, cause there had been no documentation about that at all https://issues.apache.org/jira/browse/MNGSITE-234): !debug ... which means if the property does not exist...and also works exactly like this. The value does not matter nor is needed to give some. If I argue from a logical point of view I would say (and expect): debug !true ... This would mean: The value is not equal "true"...but the property must exist...so something like "-Ddebug=WHATEVER" The current behaviour is that the previous sentence will be calculated by Maven as: The property is not important nor is needed to exists..and the values is not equal to "true"..which I think is wrong... So it is not possible to express a thing like this: environment !dev ... So this will be activated always...So the call: mvn package -Denvironment=prod mvn package would be equivalent...which I think is wrong... So it is not possible to identify a difference between those two Maven calls. Furthermore if I like to use a combination of two profiles like this: not-existing !environment ... not-dev environment !dev ... So if I call maven via: mvn package the last will take precendence... Kind regards Karl Heinz Marbaise On 12/08/16 19:32, Robert Scholte wrote: Hi, Yes, this is correct. Just to clarify: -Dx is always the same is -Dx=true [1] I'd like to add -Dprofilea= : profile activated 5. mvn initialize -Dprofilea= : profile activated maybe if the property was called skipITs instead of profilea the examples are better to follow, i.e. always activate this profile (with integration-tests), *unless* skipITs is true. Robert [1] https://maven.apache.org/ref/3.3.9/maven-embedder/xref/org/apache/maven/cli/MavenCli.html#L1544 On Fri, 12 Aug 2016 18:59:14 +0200, Guillaume Boué wrote: Hi Robert, If this is expected, I think the documentation in http://maven.apache.org/guides/introduction/introduction-to-profiles.html should indeed be clarified. Currently, in that situation, it says "The following profile will be activated when the system property "debug" is defined with a value which is not "true"." In this case, when invoking Maven with "mvn initialize", profilea isn't defined so I would expect the profile not to be activated. This is also what would happen if the value in the profile activation was commented out. To recap, this is the current result with Maven 3.3.9 for this situation (and latest 3.4.0-SNAPSHOT): 1. mvn initialize: profile activated 2. mvn initialize -Dprofilea: profile not activated 3. mvn initialize -Dprofilea=false: profile activated 4. mvn initialize -Dprofilea=true: profile not activated Guillaume Message du 12/08/16 18:34 De : "Robert Scholte" A : "Maven Developers List" Copie à : Objet : Re: Profile Activation Hi Karl Heinz, you should read the activation like this: always activate, *unless* profilea is true. So it says nothing about the availability of the property. Maybe the documentation isn't clear enough. Robert On Fri, 12 Aug 2016 17:45:21 +0200, Karl Heinz Marbaise wrote: > Hi to all, > > I have the following profile: > > > > profile-not-value-true > > > profilea > !true > > > > > > com.soebes.maven.plugins > echo-maven-plugin > > > initialize > > echo > > > > > > profile not value true > > > > > > > > So the question is: What would you expect you need to do to
Re: Profile Activation
Hi, First I have added the documentation about the opportunities like this (and other one as well a few days before, cause there had been no documentation about that at all https://issues.apache.org/jira/browse/MNGSITE-234): !debug ... which means if the property does not exist...and also works exactly like this. The value does not matter nor is needed to give some. If I argue from a logical point of view I would say (and expect): debug !true ... This would mean: The value is not equal "true"...but the property must exist...so something like "-Ddebug=WHATEVER" The current behaviour is that the previous sentence will be calculated by Maven as: The property is not important nor is needed to exists..and the values is not equal to "true"..which I think is wrong... So it is not possible to express a thing like this: environment !dev ... So this will be activated always...So the call: mvn package -Denvironment=prod mvn package would be equivalent...which I think is wrong... So it is not possible to identify a difference between those two Maven calls. Furthermore if I like to use a combination of two profiles like this: not-existing !environment ... not-dev environment !dev ... So if I call maven via: mvn package the last will take precendence... Kind regards Karl Heinz Marbaise On 12/08/16 19:32, Robert Scholte wrote: Hi, Yes, this is correct. Just to clarify: -Dx is always the same is -Dx=true [1] I'd like to add -Dprofilea= : profile activated 5. mvn initialize -Dprofilea= : profile activated maybe if the property was called skipITs instead of profilea the examples are better to follow, i.e. always activate this profile (with integration-tests), *unless* skipITs is true. Robert [1] https://maven.apache.org/ref/3.3.9/maven-embedder/xref/org/apache/maven/cli/MavenCli.html#L1544 On Fri, 12 Aug 2016 18:59:14 +0200, Guillaume Boué wrote: Hi Robert, If this is expected, I think the documentation in http://maven.apache.org/guides/introduction/introduction-to-profiles.html should indeed be clarified. Currently, in that situation, it says "The following profile will be activated when the system property "debug" is defined with a value which is not "true"." In this case, when invoking Maven with "mvn initialize", profilea isn't defined so I would expect the profile not to be activated. This is also what would happen if the value in the profile activation was commented out. To recap, this is the current result with Maven 3.3.9 for this situation (and latest 3.4.0-SNAPSHOT): 1. mvn initialize: profile activated 2. mvn initialize -Dprofilea: profile not activated 3. mvn initialize -Dprofilea=false: profile activated 4. mvn initialize -Dprofilea=true: profile not activated Guillaume Message du 12/08/16 18:34 De : "Robert Scholte" A : "Maven Developers List" Copie à : Objet : Re: Profile Activation Hi Karl Heinz, you should read the activation like this: always activate, *unless* profilea is true. So it says nothing about the availability of the property. Maybe the documentation isn't clear enough. Robert On Fri, 12 Aug 2016 17:45:21 +0200, Karl Heinz Marbaise wrote: > Hi to all, > > I have the following profile: > > > > profile-not-value-true > > > profilea > !true > > > > > > com.soebes.maven.plugins > echo-maven-plugin > > > initialize > > echo > > > > > > profile not value true > > > > > > > > So the question is: What would you expect you need to do to activate > this profile? > > Currently this profile is activated cause if I don't define the property > "profilea" at all it seemed to that Maven is assuming this means "not > value 'true'" ? > > I have assumed it should be activated if the property exists which means > giving it on command line like this: > > mvn -Dprofilea > > > > WDYT ? > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For ad
Re: Profile Activation
On 12/08/16 18:34, Robert Scholte wrote: Maybe the documentation isn't clear enough. I have added the documentation about the property activation with "!" things a few days ago... Either my assumption was wrong or the the intention is wrong... Kind regards Karl Heinz - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Profile Activation
Hi, Yes, this is correct. Just to clarify: -Dx is always the same is -Dx=true [1] I'd like to add -Dprofilea= : profile activated 5. mvn initialize -Dprofilea= : profile activated maybe if the property was called skipITs instead of profilea the examples are better to follow, i.e. always activate this profile (with integration-tests), *unless* skipITs is true. Robert [1] https://maven.apache.org/ref/3.3.9/maven-embedder/xref/org/apache/maven/cli/MavenCli.html#L1544 On Fri, 12 Aug 2016 18:59:14 +0200, Guillaume Boué wrote: Hi Robert, If this is expected, I think the documentation in http://maven.apache.org/guides/introduction/introduction-to-profiles.html should indeed be clarified. Currently, in that situation, it says "The following profile will be activated when the system property "debug" is defined with a value which is not "true"." In this case, when invoking Maven with "mvn initialize", profilea isn't defined so I would expect the profile not to be activated. This is also what would happen if the value in the profile activation was commented out. To recap, this is the current result with Maven 3.3.9 for this situation (and latest 3.4.0-SNAPSHOT): 1. mvn initialize: profile activated 2. mvn initialize -Dprofilea: profile not activated 3. mvn initialize -Dprofilea=false: profile activated 4. mvn initialize -Dprofilea=true: profile not activated Guillaume Message du 12/08/16 18:34 De : "Robert Scholte" A : "Maven Developers List" Copie à : Objet : Re: Profile Activation Hi Karl Heinz, you should read the activation like this: always activate, *unless* profilea is true. So it says nothing about the availability of the property. Maybe the documentation isn't clear enough. Robert On Fri, 12 Aug 2016 17:45:21 +0200, Karl Heinz Marbaise wrote: > Hi to all, > > I have the following profile: > > > > profile-not-value-true > > > profilea > !true > > > > > > com.soebes.maven.plugins > echo-maven-plugin > > > initialize > > echo > > > > > > profile not value true > > > > > > > > So the question is: What would you expect you need to do to activate > this profile? > > Currently this profile is activated cause if I don't define the property > "profilea" at all it seemed to that Maven is assuming this means "not > value 'true'" ? > > I have assumed it should be activated if the property exists which means > giving it on command line like this: > > mvn -Dprofilea > > > > WDYT ? > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Profile Activation
Hi Robert, If this is expected, I think the documentation in http://maven.apache.org/guides/introduction/introduction-to-profiles.html should indeed be clarified. Currently, in that situation, it says "The following profile will be activated when the system property "debug" is defined with a value which is not "true"." In this case, when invoking Maven with "mvn initialize", profilea isn't defined so I would expect the profile not to be activated. This is also what would happen if the value in the profile activation was commented out. To recap, this is the current result with Maven 3.3.9 for this situation (and latest 3.4.0-SNAPSHOT): 1. mvn initialize: profile activated 2. mvn initialize -Dprofilea: profile not activated 3. mvn initialize -Dprofilea=false: profile activated 4. mvn initialize -Dprofilea=true: profile not activated Guillaume > Message du 12/08/16 18:34 > De : "Robert Scholte" > A : "Maven Developers List" > Copie à : > Objet : Re: Profile Activation > > Hi Karl Heinz, > > you should read the activation like this: > always activate, *unless* profilea is true. > So it says nothing about the availability of the property. > Maybe the documentation isn't clear enough. > > Robert > > On Fri, 12 Aug 2016 17:45:21 +0200, Karl Heinz Marbaise > wrote: > > > Hi to all, > > > > I have the following profile: > > > > > > > > profile-not-value-true > > > > > > profilea > > !true > > > > > > > > > > > > com.soebes.maven.plugins > > echo-maven-plugin > > > > > > initialize > > > > echo > > > > > > > > > > > > profile not value true > > > > > > > > > > > > > > > > So the question is: What would you expect you need to do to activate > > this profile? > > > > Currently this profile is activated cause if I don't define the property > > "profilea" at all it seemed to that Maven is assuming this means "not > > value 'true'" ? > > > > I have assumed it should be activated if the property exists which means > > giving it on command line like this: > > > > mvn -Dprofilea > > > > > > > > WDYT ? > > > > Kind regards > > Karl Heinz Marbaise > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Profile Activation
Hi Karl Heinz, you should read the activation like this: always activate, *unless* profilea is true. So it says nothing about the availability of the property. Maybe the documentation isn't clear enough. Robert On Fri, 12 Aug 2016 17:45:21 +0200, Karl Heinz Marbaise wrote: Hi to all, I have the following profile: profile-not-value-true profilea !true com.soebes.maven.plugins echo-maven-plugin initialize echo profile not value true So the question is: What would you expect you need to do to activate this profile? Currently this profile is activated cause if I don't define the property "profilea" at all it seemed to that Maven is assuming this means "not value 'true'" ? I have assumed it should be activated if the property exists which means giving it on command line like this: mvn -Dprofilea WDYT ? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Profile Activation
MG>quick comment > To: dev@maven.apache.org > From: khmarba...@gmx.de > Subject: Profile Activation > Date: Fri, 12 Aug 2016 17:45:21 +0200 > > Hi to all, > > I have the following profile: > > > >profile-not-value-true > > >profilea >!true > > > > > > com.soebes.maven.plugins > echo-maven-plugin > > > initialize > >echo > > > > > > profile not value true > > > > > > > > So the question is: What would you expect you need to do to activate > this profile? > > Currently this profile is activated cause if I don't define the property > "profilea" at all it seemed to that Maven is assuming this means "not > value 'true'" ? > > I have assumed it should be activated if the property exists which means > giving it on command line like this: > > mvn -DprofileaMG>assumes the property *must* exist as documented at MG>http://maven.apache.org/guides/introduction/introduction-to-profiles.html MG>if ok for system property to not exist or system property to *not* be defined then either: MG>fix code to detect system property must exist to conform to doc MG>ORMG>change doc to say : The following profile will be activated when the system property "debug" is defined with a value which is not "true" -OR- when system property "debug" does not exist or when system property "debug" was never defined > MG>*Methinks you found a bug Karl* > > WDYT ? > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org >
Re: Profile activation by missing file doesn't works
Felix Knecht wrote:
> Hi all
>
> The foofoo profile is always activated, no matter if a file 'timestamp'
> exists in the same directory like the pom.xml or
> not. It looks to me as the ${basedir} is not correctly resolved. Is this a
> known problem?
http://jira.codehaus.org/browse/MNG-3524
>
> Thanks
> Felix
>
> [EMAIL PROTECTED] ~/tmp $ cat pom.xml
>xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
>
> bar
> foo
> 1.0.0
> foobar
> jar
>
>
>
> foofoo
>
>
> ${basedir}/timestamp
>
>
>
>
>
>
> [EMAIL PROTECTED] ~/tmp $ touch timestamp
> [EMAIL PROTECTED] ~/tmp $ mvn help:active-profiles
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO]
>
> [INFO] Building foobar
> [INFO]task-segment: [help:active-profiles] (aggregator-style)
> [INFO]
>
> [INFO] [help:active-profiles]
> [INFO]
> Active Profiles for Project 'bar:foo:jar:1.0.0':
>
> The following profiles are active:
>
> - foofoo (source: pom)
>
>
>
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Fri Sep 26 15:22:51 CEST 2008
> [INFO] Final Memory: 19M/64M
> [INFO]
>
> [EMAIL PROTECTED] ~/tmp $ rm timestamp
> [EMAIL PROTECTED] ~/tmp $ mvn help:active-profiles
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO]
>
> [INFO] Building foobar
> [INFO]task-segment: [help:active-profiles] (aggregator-style)
> [INFO]
>
> [INFO] [help:active-profiles]
> [INFO]
> Active Profiles for Project 'bar:foo:jar:1.0.0':
>
> The following profiles are active:
>
> - foofoo (source: pom)
>
>
>
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Fri Sep 26 15:22:58 CEST 2008
> [INFO] Final Memory: 19M/64M
> [INFO]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Dennis Lundberg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation by missing file doesn't works
Is there a JIRA in for this?
nicolas de loof wrote:
Profile activation doesn't support property interopolation, even the
${basedir} one
This makes this feature unusable in nested modules configuration, as the
file are tested from current dir, not active project root...
I already reported this issue in JIRA.
Nicolas
2008/9/26 Felix Knecht <[EMAIL PROTECTED]>
Hi all
The foofoo profile is always activated, no matter if a file 'timestamp'
exists in the same directory like the pom.xml or
not. It looks to me as the ${basedir} is not correctly resolved. Is this a
known problem?
Thanks
Felix
[EMAIL PROTECTED] ~/tmp $ cat pom.xml
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
bar
foo
1.0.0
foobar
jar
foofoo
${basedir}/timestamp
[EMAIL PROTECTED] ~/tmp $ touch timestamp
[EMAIL PROTECTED] ~/tmp $ mvn help:active-profiles
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building foobar
[INFO]task-segment: [help:active-profiles] (aggregator-style)
[INFO]
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'bar:foo:jar:1.0.0':
The following profiles are active:
- foofoo (source: pom)
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Fri Sep 26 15:22:51 CEST 2008
[INFO] Final Memory: 19M/64M
[INFO]
[EMAIL PROTECTED] ~/tmp $ rm timestamp
[EMAIL PROTECTED] ~/tmp $ mvn help:active-profiles
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building foobar
[INFO]task-segment: [help:active-profiles] (aggregator-style)
[INFO]
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'bar:foo:jar:1.0.0':
The following profiles are active:
- foofoo (source: pom)
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Fri Sep 26 15:22:58 CEST 2008
[INFO] Final Memory: 19M/64M
[INFO]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation by missing file doesn't works
nicolas de loof schrieb:
> Profile activation doesn't support property interopolation, even the
> ${basedir} one
> This makes this feature unusable in nested modules configuration, as the
> file are tested from current dir, not active project root...
> I already reported this issue in JIRA.
>
Thanks Nicolas.
In this case the documentation is wrong:
http://maven.apache.org/pom.html#Activation
Felix
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation by missing file doesn't works
Profile activation doesn't support property interopolation, even the
${basedir} one
This makes this feature unusable in nested modules configuration, as the
file are tested from current dir, not active project root...
I already reported this issue in JIRA.
Nicolas
2008/9/26 Felix Knecht <[EMAIL PROTECTED]>
> Hi all
>
> The foofoo profile is always activated, no matter if a file 'timestamp'
> exists in the same directory like the pom.xml or
> not. It looks to me as the ${basedir} is not correctly resolved. Is this a
> known problem?
>
> Thanks
> Felix
>
> [EMAIL PROTECTED] ~/tmp $ cat pom.xml
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
>
> bar
> foo
> 1.0.0
> foobar
> jar
>
>
>
> foofoo
>
>
> ${basedir}/timestamp
>
>
>
>
>
>
> [EMAIL PROTECTED] ~/tmp $ touch timestamp
> [EMAIL PROTECTED] ~/tmp $ mvn help:active-profiles
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO]
>
> [INFO] Building foobar
> [INFO]task-segment: [help:active-profiles] (aggregator-style)
> [INFO]
>
> [INFO] [help:active-profiles]
> [INFO]
> Active Profiles for Project 'bar:foo:jar:1.0.0':
>
> The following profiles are active:
>
> - foofoo (source: pom)
>
>
>
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Fri Sep 26 15:22:51 CEST 2008
> [INFO] Final Memory: 19M/64M
> [INFO]
>
> [EMAIL PROTECTED] ~/tmp $ rm timestamp
> [EMAIL PROTECTED] ~/tmp $ mvn help:active-profiles
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO]
>
> [INFO] Building foobar
> [INFO]task-segment: [help:active-profiles] (aggregator-style)
> [INFO]
>
> [INFO] [help:active-profiles]
> [INFO]
> Active Profiles for Project 'bar:foo:jar:1.0.0':
>
> The following profiles are active:
>
> - foofoo (source: pom)
>
>
>
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Fri Sep 26 15:22:58 CEST 2008
> [INFO] Final Memory: 19M/64M
> [INFO]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: Profile activation/deactivation
I added a proposal for some profile activation/deactivation improvements here: http://docs.codehaus.org/display/MAVENUSER/Improvements+to+Profile+Activation+Deactivation Please take a look and add comments if you are interested. Thanks! 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]
Re: Profile activation/deactivation
I agree, I think the best option for 2.0.x is to keep the current profile behaviour, with the working profile deactivation. I like the idea of being able to use "+myProfile" to add a profile without deactivating the deafault profiles. But for 2.0.x I think we should just leave the current behaviour because: 1. The change would require some changes to the ProfileManager interface and more changes to the DefaultProfileManager should probably wait until 2.1. 2. I see the "+" option as low priority because there is an easy workaround of just specifying all the profiles that you want active. For 2.1 maybe we can add an optional groupId to the profile config like you suggested. As far as reducing the overall need for profiles maybe being able to more easily control the build lifecycle would help. For example, if there was an easy way to tell the build to skip a certain phase or skip certain plugins or executions, that might cover some profile use cases. Brian E. Fox wrote: I think we should maintain the current functionality of a default deactivating when another profile in the pom is activated until there is a syntax to perform the same. I have often in the past done things like: (pseudo pom code) all true a b c ... a a Etc and the activation would be mvn xxx -Pa and the expectation is you only build a...retraining everyone to say -Pa,!all is a bit much. To accomplish this correctly, you would need to add a profile group id and if nothing is there, then the explicitly share the same group, thus preserving backwards compat while giving a bit more flexibility. I do share Jesse's sentiment about maybe we are missing something else. If there's anything in the pom that reduces clarity, it is definitely profiles. --Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jesse McConnell Sent: Thursday, May 15, 2008 11:37 AM To: Maven Developers List; [EMAIL PROTECTED] Subject: Re: Profile activation/deactivation No one can dispute the nice things that profiles let us accomplish in terms of toggling on functionalities... But I wonder much this will impact build reproducibilityespecially given the existence of profiles in the settings.xml file. It is already a source of minor pain where people need to pass around fragments of profiles to get their builds (or releases) working. I wonder how much making it easier to toggle on and off profiles will impact the future of these sorts of practices. I already have to edit my settings.xml file and comment in and out a certain profile if I want to deploy something from one place or another. I could override on the cli but thats a big pita as well. John and I talked ages ago about how profiles were basically a hack and black magic in what they allowed people to do with any given build. Seeing all of these +/-/D:/E:/! goop floating around seems to be increasing the black magic. I am torn though, profiles have helped me immeasurably in the past...even if they made me feel a touch dirty in the process. Are we missing a chance to codify some other sort of functionality that keeps build reproducibility at the forefront? And by build reproducibility I mean out of the box, not after cut and pasting magic chunks of stuff around behind the scenes. anywho, figured I would throw that out. jesse On Thu, May 15, 2008 at 10:16 AM, Ralph Goers <[EMAIL PROTECTED]> wrote: +1. My first reaction though was the thought, what should -P-profile do? Is it confusing not to have it if + is supported? Would it be the same as -P!profile? Bernhard David wrote: would it be possible to have "-Pprofile" work as usual (activate profile, deactivate defaults) but "-P+profile" add profile to the existing ones, without deactivating defaults? Or if "+" is taken we could use some other character. In any case it would be really useful to add profiles like this, for instance to support "mvn install -P+optionalTests" without having to figure out what other profiles you need manually. Greetings, David Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Profile activation/deactivation
I think we should maintain the current functionality of a default deactivating when another profile in the pom is activated until there is a syntax to perform the same. I have often in the past done things like: (pseudo pom code) all true a b c ... a a Etc and the activation would be mvn xxx -Pa and the expectation is you only build a...retraining everyone to say -Pa,!all is a bit much. To accomplish this correctly, you would need to add a profile group id and if nothing is there, then the explicitly share the same group, thus preserving backwards compat while giving a bit more flexibility. I do share Jesse's sentiment about maybe we are missing something else. If there's anything in the pom that reduces clarity, it is definitely profiles. --Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jesse McConnell Sent: Thursday, May 15, 2008 11:37 AM To: Maven Developers List; [EMAIL PROTECTED] Subject: Re: Profile activation/deactivation No one can dispute the nice things that profiles let us accomplish in terms of toggling on functionalities... But I wonder much this will impact build reproducibilityespecially given the existence of profiles in the settings.xml file. It is already a source of minor pain where people need to pass around fragments of profiles to get their builds (or releases) working. I wonder how much making it easier to toggle on and off profiles will impact the future of these sorts of practices. I already have to edit my settings.xml file and comment in and out a certain profile if I want to deploy something from one place or another. I could override on the cli but thats a big pita as well. John and I talked ages ago about how profiles were basically a hack and black magic in what they allowed people to do with any given build. Seeing all of these +/-/D:/E:/! goop floating around seems to be increasing the black magic. I am torn though, profiles have helped me immeasurably in the past...even if they made me feel a touch dirty in the process. Are we missing a chance to codify some other sort of functionality that keeps build reproducibility at the forefront? And by build reproducibility I mean out of the box, not after cut and pasting magic chunks of stuff around behind the scenes. anywho, figured I would throw that out. jesse On Thu, May 15, 2008 at 10:16 AM, Ralph Goers <[EMAIL PROTECTED]> wrote: > +1. My first reaction though was the thought, what should -P-profile do? Is > it confusing not to have it if + is supported? Would it be the same as > -P!profile? > > > Bernhard David wrote: > > > > > > > would it be possible to have "-Pprofile" work as usual (activate > > profile, deactivate defaults) but "-P+profile" add profile to the > > existing ones, without deactivating defaults? Or if "+" is taken we > > could use some other character. > > > > In any case it would be really useful to add profiles like this, for > > instance to support "mvn install -P+optionalTests" without having to > > figure out what other profiles you need manually. > > > > Greetings, > > > > David Bernhard > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation/deactivation
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: group1-profile1 true group1-profile2.on true group1-profile2 group1-profile2.on true group2-profile3 true ... 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
Re: Profile activation/deactivation
Ralph Goers wrote: 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. Seems right to me. 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. I just implemented a project where this behavior was required. In the default case I build and test with SLF4J and logback. In test 2 I test with SLF4J and Log4j. If the default was never turned off then I'd have no way of doing this unless there was no default. The idea was that you could still turn off an activeByDefault profile, just that you would have to do it using the deactivation syntax, instead of it turning off automatically when another profile is activated. Anyway, it sounds like profile usage is somewhat split between using them in a mutually exclusive way vs. using multiple profiles together, so having a way to do either of these like "-P +myprofile" vs "-P myprofile" seems like it would be useful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation/deactivation
D/E were meant to work in cases where the - leading character might be a problem. If it's never a problem, we don't need them. If the only argument to the -P option can be something like "- myProfile" (leading dash) then we have no need for it...and the ! notation might make this even better. -john On May 15, 2008, at 11:40 AM, Paul Gier wrote: 2.0.x and 2.1 work the same after your change. "+" means activate and "-" means deactivate. I'm guessing it was just a typo in 2.1 that had them reversed. What's the reason for the D: and E: syntax? Do we need these if +,-,!, can be used? John Casey wrote: I looked at the logic for +/- the other day (when I added E: and D:, fwiw), and the logic was backward, IIRC...I fixed it in 2.1, but it may still be broken in 2.0.x, not sure... -john On May 14, 2008, at 5:44 PM, Brian E. Fox wrote: Need to think about 1& 2 some more but: 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. As far as I know, the - never worked so going to ! is better...I think the 2.1 deactivation should be brought in line as well...we don't need more proliferation of changes. - 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] --- 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
Re: Profile activation/deactivation
2.0.x and 2.1 work the same after your change. "+" means activate and "-" means deactivate. I'm guessing it was just a typo in 2.1 that had them reversed. What's the reason for the D: and E: syntax? Do we need these if +,-,!, can be used? John Casey wrote: I looked at the logic for +/- the other day (when I added E: and D:, fwiw), and the logic was backward, IIRC...I fixed it in 2.1, but it may still be broken in 2.0.x, not sure... -john On May 14, 2008, at 5:44 PM, Brian E. Fox wrote: Need to think about 1& 2 some more but: 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. As far as I know, the - never worked so going to ! is better...I think the 2.1 deactivation should be brought in line as well...we don't need more proliferation of changes. - 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]
Re: Profile activation/deactivation
No one can dispute the nice things that profiles let us accomplish in terms of toggling on functionalities... But I wonder much this will impact build reproducibilityespecially given the existence of profiles in the settings.xml file. It is already a source of minor pain where people need to pass around fragments of profiles to get their builds (or releases) working. I wonder how much making it easier to toggle on and off profiles will impact the future of these sorts of practices. I already have to edit my settings.xml file and comment in and out a certain profile if I want to deploy something from one place or another. I could override on the cli but thats a big pita as well. John and I talked ages ago about how profiles were basically a hack and black magic in what they allowed people to do with any given build. Seeing all of these +/-/D:/E:/! goop floating around seems to be increasing the black magic. I am torn though, profiles have helped me immeasurably in the past...even if they made me feel a touch dirty in the process. Are we missing a chance to codify some other sort of functionality that keeps build reproducibility at the forefront? And by build reproducibility I mean out of the box, not after cut and pasting magic chunks of stuff around behind the scenes. anywho, figured I would throw that out. jesse On Thu, May 15, 2008 at 10:16 AM, Ralph Goers <[EMAIL PROTECTED]> wrote: > +1. My first reaction though was the thought, what should -P-profile do? Is > it confusing not to have it if + is supported? Would it be the same as > -P!profile? > > > Bernhard David wrote: > > > > > > > would it be possible to have "-Pprofile" work as usual (activate > > profile, deactivate defaults) but "-P+profile" add profile to the > > existing ones, without deactivating defaults? Or if "+" is taken we > > could use some other character. > > > > In any case it would be really useful to add profiles like this, for > > instance to support "mvn install -P+optionalTests" without having to > > figure out what other profiles you need manually. > > > > Greetings, > > > > David Bernhard > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation/deactivation
I looked at the logic for +/- the other day (when I added E: and D:, fwiw), and the logic was backward, IIRC...I fixed it in 2.1, but it may still be broken in 2.0.x, not sure... -john On May 14, 2008, at 5:44 PM, Brian E. Fox wrote: Need to think about 1& 2 some more but: 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. As far as I know, the - never worked so going to ! is better...I think the 2.1 deactivation should be brought in line as well...we don't need more proliferation of changes. - 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
Re: Profile activation/deactivation
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. 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
Re: Profile activation/deactivation
+1. My first reaction though was the thought, what should -P-profile do? Is it confusing not to have it if + is supported? Would it be the same as -P!profile? Bernhard David wrote: would it be possible to have "-Pprofile" work as usual (activate profile, deactivate defaults) but "-P+profile" add profile to the existing ones, without deactivating defaults? Or if "+" is taken we could use some other character. In any case it would be really useful to add profiles like this, for instance to support "mvn install -P+optionalTests" without having to figure out what other profiles you need manually. Greetings, David Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation/deactivation
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. Seems right to me. 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. I just implemented a project where this behavior was required. In the default case I build and test with SLF4J and logback. In test 2 I test with SLF4J and Log4j. If the default was never turned off then I'd have no way of doing this unless there was no default. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation/deactivation
Same use case here. IMHO having a distinction between "-P profile" and "-P +profile" is acceptable. "-P profile" may work as it does today (specify the exact list of profiles, whith auto-disabled default ones). For backward compatibility, but also to enable exclusive profiles switching. 2008/5/15 Mark Hobson <[EMAIL PROTECTED]>: > Would a concept of profile groups help to determine which profiles are > meant to be mutually exclusive? > > I use mutually exclusive profiles for different deployment > configurations, for example development and production. By default, > the development profile is actived by default, so currently > -Pproduction would disable the development profile and enable the > production profile. The proposed changes would require > -P!development,production, which is a little cumbersome and prone to > error. > > +1 for using the !-notation for disabling profiles. > > Mark > > 2008/5/14 Paul Gier <[EMAIL PROTECTED]>: > > > > 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] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Profile activation/deactivation
Would a concept of profile groups help to determine which profiles are meant to be mutually exclusive? I use mutually exclusive profiles for different deployment configurations, for example development and production. By default, the development profile is actived by default, so currently -Pproduction would disable the development profile and enable the production profile. The proposed changes would require -P!development,production, which is a little cumbersome and prone to error. +1 for using the !-notation for disabling profiles. Mark 2008/5/14 Paul Gier <[EMAIL PROTECTED]>: > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation/deactivation
I like this suggestion. using -P !profile to disable a profile is consistent with negation in properties activation, but the "-" symbol is also fine, if the feature works ;-) using -P +profile is a comprehensible way to *add* a profile to the default active profile list. But some may prefer to use another symbol ? considering those two options, using -P profile to set from the command line the *exact *list of profiles to be enabled (disable default active profiles) is consistent. Maven 2.1 syntax for profiles is not very nice to read... I'd prefer either the same +/- syntax, or some --enable-profile x (-P x), --disable-profile y (-dP y) 2008/5/15 Bernhard David <[EMAIL PROTECTED]>: > Hello, > > here's a suggestion Re. point 2 > > > 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. > > would it be possible to have "-Pprofile" work as usual (activate > profile, deactivate defaults) but "-P+profile" add profile to the > existing ones, without deactivating defaults? Or if "+" is taken we > could use some other character. > > In any case it would be really useful to add profiles like this, for > instance to support "mvn install -P+optionalTests" without having to > figure out what other profiles you need manually. > > Greetings, > > David Bernhard > > > > -Original Message- > > From: Jesse McConnell [mailto:[EMAIL PROTECTED] > > Sent: 15 May 2008 00:04 > > To: Maven Developers List > > Subject: Re: Profile activation/deactivation > > > > I think the ! is probably better then D: E: E: > > > > jesse > > > > On Wed, May 14, 2008 at 4:51 PM, Paul Gier <[EMAIL PROTECTED]> wrote: > > > Brian E. Fox wrote: > > > > > > > > > > > Need to think about 1& 2 some more but: > > > > > > > > > > > > > 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. > > > > > > > > > > > > > As far as I know, the - never worked so going to ! is > > better...I think > > > > the 2.1 deactivation should be brought in line as > > well...we don't need > > > > more proliferation of changes. > > > > > > > > > > > > > > Should I remove both "-" and "+" since they would both be > > redundant if we > > > add "!"? > > > > > > So some examples would be: > > > mvn -P !profile1,profile2,profile3 > > > > > > And in maven 2.1 currently this can also be expressed with: > > > mvn -P D:profile1,E:profile2,E:profile3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > -- > > jesse mcconnell > > [EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: Profile activation/deactivation
Hello, here's a suggestion Re. point 2 > 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. would it be possible to have "-Pprofile" work as usual (activate profile, deactivate defaults) but "-P+profile" add profile to the existing ones, without deactivating defaults? Or if "+" is taken we could use some other character. In any case it would be really useful to add profiles like this, for instance to support "mvn install -P+optionalTests" without having to figure out what other profiles you need manually. Greetings, David Bernhard > -Original Message- > From: Jesse McConnell [mailto:[EMAIL PROTECTED] > Sent: 15 May 2008 00:04 > To: Maven Developers List > Subject: Re: Profile activation/deactivation > > I think the ! is probably better then D: E: E: > > jesse > > On Wed, May 14, 2008 at 4:51 PM, Paul Gier <[EMAIL PROTECTED]> wrote: > > Brian E. Fox wrote: > > > > > > > > Need to think about 1& 2 some more but: > > > > > > > > > > 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. > > > > > > > > > > As far as I know, the - never worked so going to ! is > better...I think > > > the 2.1 deactivation should be brought in line as > well...we don't need > > > more proliferation of changes. > > > > > > > > > > Should I remove both "-" and "+" since they would both be > redundant if we > > add "!"? > > > > So some examples would be: > > mvn -P !profile1,profile2,profile3 > > > > And in maven 2.1 currently this can also be expressed with: > > mvn -P D:profile1,E:profile2,E:profile3 > > > > > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > jesse mcconnell > [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Profile activation/deactivation
>Should I remove both "-" and "+" since they would both be redundant if we add "!"? I would. >So some examples would be: >mvn -P !profile1,profile2,profile3 Yep. >And in maven 2.1 currently this can also be expressed with: >mvn -P D:profile1,E:profile2,E:profile3 I would make it the same as 2.0 above. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation/deactivation
I think the ! is probably better then D: E: E: jesse On Wed, May 14, 2008 at 4:51 PM, Paul Gier <[EMAIL PROTECTED]> wrote: > Brian E. Fox wrote: > > > > > Need to think about 1& 2 some more but: > > > > > > > 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. > > > > > > > As far as I know, the - never worked so going to ! is better...I think > > the 2.1 deactivation should be brought in line as well...we don't need > > more proliferation of changes. > > > > > > Should I remove both "-" and "+" since they would both be redundant if we > add "!"? > > So some examples would be: > mvn -P !profile1,profile2,profile3 > > And in maven 2.1 currently this can also be expressed with: > mvn -P D:profile1,E:profile2,E:profile3 > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation/deactivation
Brian E. Fox wrote: Need to think about 1& 2 some more but: 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. As far as I know, the - never worked so going to ! is better...I think the 2.1 deactivation should be brought in line as well...we don't need more proliferation of changes. Should I remove both "-" and "+" since they would both be redundant if we add "!"? So some examples would be: mvn -P !profile1,profile2,profile3 And in maven 2.1 currently this can also be expressed with: mvn -P D:profile1,E:profile2,E:profile3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Profile activation/deactivation
Need to think about 1& 2 some more but: >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. As far as I know, the - never worked so going to ! is better...I think the 2.1 deactivation should be brought in line as well...we don't need more proliferation of changes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation/deactivation
Paul Gier wrote: 3. There was a suggestion to allow the use of "!" to disable a profile. So the command line would look like: mvn -P!myProfile Unless some severe drawback is reported, +1 on this because "!" is quite natural among programmers for negation and also matches the existing syntax for negation of profile activation conditions in the POM. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
