Hi Curtis,

yes, using property activation is more or less the workaround described in
MNG-4533.

If I had to pick a workaround, I would prefer checking for the existence of
pom.xml. This is guaranteed to always return true. So the only way to
deactivate the profile would be to deactivate it explicitly with
-P!profile. With property activation a user of the project could either
deactivate the profile with -P or change the property. But that's probably
a matter of personal preference.

Best regards,
Arend


On Sat, Nov 14, 2015 at 10:19 PM, Curtis Rueden <ctrue...@wisc.edu> wrote:

> 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 <ar...@arendvr.com>
> 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 <khmarba...@gmx.de>
> > 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: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>

Reply via email to