Hi, Lee. Thanks for response. Activating the profiles based on an environment variable seems to be better than activating them fully in settings.xml, but to do so I would still have one step before the ' mvn -Pprofile1,profile2 package '. My intention when I first submitted the email to the list was to know if there is an even simpler way to do that just by running something like ' mvn <magic_argument> -Pprofile1,profile2 package ' as I said before.
For now, I´m working like the easiest possible way that I know of: The profiles I need to be active by default are configure with <activeByDefault>true</activeByDefault> . If one developer needs to do something unusual, he simply runs ' mvn -Pprofile1,profile2 package ' . By doing so, all the "activeByDefault" profiles will be automatically deactivated and only the profiles explicitly defined will be activated. I was trying to activate profiles using the settings.xml just because I did not want the default profiles configuration to be shared between developers, i.e., I did not want to share these informations on the pom.xml that is on the version control system. On Fri, Mar 25, 2011 at 6:32 PM, Lee Meador <[email protected]> wrote: > What if you don't activate the profiles fully in settings.xml, don't > activate them by default in settings.xml but, instead, activate them based > on an environment variable on the machine? > > You could "set MAVEN_SETTINGS_PROFILES=default" in the startup for the > developer's workstation/laptop. Then put in the option to activate those > default profiles > > <profiles> > <profile> > <activation> > <property> > <name>env.MAVEN_SETTINGS_PROFILES</name> > <value>default</value> > </property> > </activation> > ... > </profile> > </profiles> > > > If that developer is going to be doing something unusual, they would clear > the value of the environment variable and use the -Pprofile1,profile2 > command line profile setter when building the non-standard stuff. > > Thanks. > > Lee > > On Fri, Mar 25, 2011 at 4:02 PM, Rafael Vanderlei < > [email protected] > > wrote: > > > Hi, Wendy. > > > > I have many dependencies on runtime and they vary on many environments. > > > > Basically, my application must be able to run in 5 different > environments, > > named local (which actually is the machine of the developer), > development, > > integration, trainning and production. In which of those environments, I > > have other applications on which mine depends and so I have a bunch of > > combinations of profiles for each environment and for each application on > > which mine depends. > > > > The whole organization of environments/applications is something like > this: > > > > - Enviroment 1 > > --- MyApplication, Application B, Application C, Application D, > Application > > E > > - Enviroment 2 > > --- MyApplication, Application B, Application C, Application D, > Application > > E > > - Enviroment 3 > > --- MyApplication, Application B, Application C, Application D, > Application > > E > > - Enviroment 4 > > --- MyApplication, Application B, Application C, Application D, > Application > > E > > - Enviroment 5 > > --- MyApplication, Application B, Application C, Application D, > Application > > E > > > > > > I need my build configuration to be flexible enough to allow someone to > > build "MyApplication" for the Environment1 that uses "Application B" that > > runs on "Environment 2", "Application C that runs on Environment 3"... > > well.. any variations of those Apps and Envs.. > > > > So, the default profiles are supposed to determine the configuration of > the > > local enviroment, which is the machine of each developer, but when I try > to > > build for another environment, I dont want the default profiles to be > > activated, because they will contain configurations specific only for the > > local environment and those default profiles come into direct conflict > with > > the profiles for the other environments. > > > > I think people may be confused by reading all these explanations about > the > > real case I´m working on and that´s why I tried to hide it on the first > > post > > and questioned only specific details about Maven profiles, which I think > > would easier to analyse and answer. > > > > I hope this helped more than messed things up lol. > > > > Regards, > > > > Rafael. > > > > > > On Fri, Mar 25, 2011 at 5:30 PM, Wendy Smoak <[email protected]> wrote: > > > > > On Fri, Mar 25, 2011 at 12:18 PM, Rafael Vanderlei > > > <[email protected]> wrote: > > > > > > > If I configure my .m2/settings.xml to activate some profiles, is > there > > a > > > way > > > > to deactivate all of them on the command line "in one go", so I can > > use > > > > only explicitly typed profiles? > > > > > > Why are there so many profiles and what are they for? > > > > > > (If you explain what problem you're trying to solve, someone can > > > probably help you come up with a better solution. Clearly, having a > > > bunch of profiles that are active by default and then wanting them to > > > NOT be active indicates something is wrong.) > > > > > > -- > > > Wendy > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > -- > -- Lee Meador > Sent from gmail. My real email address is lee AT leemeador.com >
