Hi Arend, > The idea is to have a profile which is always active, unless > explicitly deactivated.
To achieve that use case, I like to activate based on a property value. Then you can change the property value from the CLI to deactivate it, without affecting any other profiles. This is more flexible than using the -P flag (which I avoid whenever possible). Regards, Curtis On Sat, Nov 14, 2015 at 3:06 PM, Arend v. Reinersdorff <[email protected]> wrote: > Hi Karl Heinz, > > good point. I'll try to elaborate more: > > The idea is to have a profile which is always active, unless explicitly > deactivated. One can nearly achieve this with > <activeByDefault>true</activeByDefault>, but not quite because an > activeByDefault profile is deactivated if another profile from the same > pom.xml is activated. > > So this is needed when: > - one profile should always be active, but can be turned off explicitly > - another profile can be activated, and activating it should not deactivate > the always active profile > > > Here's a concrete example. Solution taken from this answer on Stackoverflow > > http://stackoverflow.com/questions/5539348/how-to-exclude-a-module-from-a-maven-reactor-build/11429945#11429945 > > - a multi module project > - normally all modules are included in a build > - in some cases certain modules (data-foo and data-bar) should be excluded > from the build (in the Stackoverflow question because the tests took a long > time, I was researching it to exclude modules from Javadoc generation) The > modules are excluded with "mvn -!Pfull-build" > - also, there's another profile to change the target directory. Activating > this should not interfere with module exclusion. "mvn -PtargetInTemp clean > install" should still build all modules. > > <!-- modules always included --> > <modules> > <module>common</module> > <module>foo</module> > <module>bar</module> > </modules> > > <profiles> > <profile> > <id>full-build</id> > <activation> > > <!-- current, ugly workaround for an always active profile > MNG-4533 would improve this --> > <file> > <exists>pom.xml</exists> > </file> > > </activation> > <modules> > <module>data-foo</module> > <module>data-bar</module> > </modules> > </profile> > > <profile> > <!-- A profile commonly found in our company. Moves the target > directory to $TEMP. > To build the project without interference from Eclipse. --> > <id>targetInTemp</id> > <build> > > <directory>${env.TEMP}/${project.groupId}/${project.artifactId}</directory> > </build> > </profile> > </profiles> > > > Best regards, > Arend > > > On Sat, Nov 14, 2015 at 2:20 PM, Karl Heinz Marbaise <[email protected]> > wrote: > > > Hi, > > > > On 11/14/15 2:03 PM, Arend v. Reinersdorff wrote: > > > >> Hi, > >> > >> could issue MNG-4533 "Add an always active profile activator" please be > >> reopened? > >> https://issues.apache.org/jira/browse/MNG-4533 > >> > >> The issues was automatically closed in 2014. > >> > >> I find the current workarounds to create an always active profile (check > >> for non existing property, check for always existing file) quite ugly. > >> > > > > > > The question is why do you need a profile which is always active ? In > > consequence i would ask why do you need a profile at all in such case? If > > it is always active you don't need a profile.... > > > > > > May be you can elaborate more what you like to achieve and what the use > > case is? > > > > > > Kind regards > > Karl Heinz Marbaise > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
