[jira] Subscription: Design & Best Practices
Issue Subscription Filter: Design & Best Practices (29 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-3313NetBeans projects, more than ant project, more than free form project. http://jira.codehaus.org/browse/MNG-3313 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-2584Rebuild on pom change http://jira.codehaus.org/browse/MNG-2584 MNG-139 server definitions should be reusable - review use of repository IDs http://jira.codehaus.org/browse/MNG-139 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-868 Use uniform format for and other tags http://jira.codehaus.org/browse/MNG-868 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 - 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: Artifact Version Comparison
FYI, I just merged version comparison improvement to artifact trunk. 2.1.x ITs are ok, both on my machine and on Sonatype's CI server I hope everything is ok for everybody Don't hesitate to ring me if anything goes wrong regards, Hervé Le jeudi 01 mai 2008, Hervé BOUTEMY a écrit : > Kenney started a proposal http://docs.codehaus.org/display/MAVEN/Versioning > with a implementation of a comparator. > > I took his implementation, updated it to support comparison between more > version schemes and integrated it to DefaultArtifactVersion class. The code > is here http://svn.apache.org/viewvc/maven/artifact/branches/MNG-3010/, > with unit test showing version schemes in action: > http://svn.apache.org/viewvc/maven/artifact/branches/MNG-3010/src/test/java >/org/apache/maven/artifact/versioning/ComparableVersionTest.java > > I think the new ordering will give better results than the current one and > would like to merge it to artifact trunk and 2.0.x branch. Before doing so, > I submit the code for review: any comments? > > regards, > > Hervé > > - > 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]
[ANN] Maven Surefire 2.4.3 Released
The Maven team is pleased to announce the release of the Maven Surefire, version 2.4.3. Maven Surefire is used during the "test" phase of the build lifecycle to execute your unit tests. It supports JUnit 3 & 4 as well as TestNG, and generates TXT, XML and HTML reports. http://maven.apache.org/plugins/maven-surefire-plugin/ You can specify the plugin version in your project's plugin configuration: org.apache.maven.plugins maven-surefire-plugin 2.4.3 Surefire 2.4.3 requires Maven 2.0.6 or higher. Release Notes - Maven Surefire - Version 2.4.3 ** Bug * [SUREFIRE-264] - XRef links do not work with aggregated reports on windows * [SUREFIRE-423] - Output a title for the report * [SUREFIRE-440] - Fix serialization of File[] into properties for forked Surefire run * [SUREFIRE-459] - Integration test using Jetty and JSP 2.1 fails after update to maven-surefire-plugin 2.4 * [SUREFIRE-460] - surefire-api manifest content is wrong: it is a copy of commons-lang * [SUREFIRE-463] - ClassCastException when using testng suiteXmlFile and forkMode=always * [SUREFIRE-467] - NoSuchMethodError UrlUtils.getURL when using JDK3 for testing * [SUREFIRE-481] - java.lang.NoSuchMethodError when forking on a 1.3 JDK * [SUREFIRE-491] - All system properties from Maven process are copied to forked Surefire process * [SUREFIRE-492] - Allow "test" parameter to override suiteXmlFiles * [SUREFIRE-493] - UrlUtilsTest fails ** Improvement * [SUREFIRE-422] - Strip "Maven" from report title * [SUREFIRE-426] - Add german translation * [SUREFIRE-473] - Documentation for additionalClassPath feature * [SUREFIRE-474] - Allow TestNG to use its built-in HTMLReporter * [SUREFIRE-484] - Don't output empty tables * [SUREFIRE-485] - Support AntUnit XML output * [SUREFIRE-490] - Provide an option to use simplified classloading ** Task * [SUREFIRE-488] - Document TestNG listeners/reporters * [SUREFIRE-489] - Document classpath issues Enjoy, -The Maven team - 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]
