You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Arend v. Reinersdorff" <ar...@arendvr.com> on 2015/11/14 14:03:28 UTC
Please reopen MNG-4533 Add an always active profile activator
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.
Best regards,
Arend
Re: Please reopen MNG-4533 Add an always active profile activator
Posted by Robert Scholte <rf...@apache.org>.
Hi,
I don't think that it is documented, but we should once we decide to have
a clear separation between the build-pom and the consumer-pom. Now the
same pom is used for different purposes. Also in general we advice to
avoid profiles (it exposes some design flaws), so maybe better not talk
about their existence ;)
thanks,
Robert
Op Tue, 24 Nov 2015 11:23:40 +0100 schreef Arend v. Reinersdorff
<ar...@arendvr.com>:
> Hi,
>
> yes, this is only about build time profiles. Including modules is only
> relevant during build time. And I assume the profile of a dependency
> cannot
> change the main project's target directory. So for this use case it's
> irrelevant whether the profiles would be active or not active during
> consume time. The profiles wouldn't have any effect at consume time
> anyway.
>
> Interesting to now that file-based activation is not used during consume
> time. Makes a lot of sense. Do you know if this is documented anywhere?
>
> Best regards,
> Arend
>
>
> On Mon, Nov 23, 2015 at 11:08 PM, Robert Scholte <rf...@apache.org>
> wrote:
>
>> Hi,
>>
>> One other thing that comes to my mind: is this a build/site time profile
>> or also a "consume"-time profile.
>> With the latter I mean: should the profile have any effect when its
>> artifact is used as a dependency?
>> I think the answer is 'no', which means that the profile shouldn't
>> always
>> be active.
>> File-based activation of profiles is also used only during build/site
>> time, so your workaround seems quite valid to me.
>>
>> regards,
>> Robert
>>
>> Op Mon, 23 Nov 2015 16:33:17 +0100 schreef Arend v. Reinersdorff <
>> arend@arendvr.com>:
>>
>>
>> Hi,
>>>
>>> it seems there are no more questions about the use case.
>>>
>>> So I'd like to return to my original request:
>>> Could issue MNG-4533 "Add an always active profile activator" please be
>>> reopened?
>>> https://issues.apache.org/jira/browse/MNG-4533
>>>
>>> Best regards,
>>> Arend
>>>
>>>
>>> On Sun, Nov 15, 2015 at 1:44 PM, Arend v. Reinersdorff
>>> <arend@arendvr.com
>>> >
>>> wrote:
>>>
>>> On Sat, Nov 14, 2015 at 11:02 PM, Karl Heinz Marbaise
>>> <kh...@gmx.de>
>>>> wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> On 11/14/15 10:06 PM, Arend v. Reinersdorff 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,
>>>>>>
>>>>>>
>>>>>
>>>>> Ok...starting with Maven 3.2.1[1] you can use things like this:
>>>>>
>>>>>
>>>>> mvn -pl !moduleYouDontLikeToBuild package
>>>>>
>>>>> So no need for a profile...I'm just quoting the answers which already
>>>>> given on SO...
>>>>>
>>>>> Yes, that's the solution I use at the moment. Problems:
>>>> 1) I think mvn -Pjavadoc would be much nicer and cleaner than mvn -pl
>>>> !data-foo !data-bar javadoc:aggregate
>>>> 2) I think this is OK for two modules, but using this to exclude
>>>> three or
>>>> more modules would be too ugly.
>>>>
>>>> Apart from that if you have tests which run long you should think if
>>>> those
>>>>
>>>>> tests are really unit- or integration tests...which means different
>>>>> life
>>>>> cycle phases etc. and never activate/deactivate modules via
>>>>> profiles[2]
>>>>>
>>>>>
>>>>> [1]: http://maven.apache.org/docs/3.2.1/release-notes.html
>>>>> [2]:
>>>>>
>>>>> http://blog.soebes.de/blog/2013/11/09/why-is-it-bad-to-activate-slash-deactive-modules-by-profiles-in-maven/
>>>>>
>>>>> The blog post you link in [2] correctly points out the problem with
>>>> using
>>>> modules in profiles: Which is that someone might forget to activate
>>>> the
>>>> profile, for example when doing a release. The conclusion of the blog
>>>> post
>>>> is to not use modules in profiles. That's where I disagree. I think
>>>> using
>>>> modules in profiles can be OK if the profile is always activated
>>>> unless
>>>> deactivated by default.
>>>>
>>>>
>>>> >
>>>>> I was researching it to exclude modules from Javadoc
>>>>>
>>>>> generation) The modules are excluded with "mvn -!Pfull-build"
>>>>>>
>>>>>>
>>>>> The above can also be applied to exclude from JavaDoc ...I'm asking
>>>>> myself why you like to exclude a module from JavaDoc generation but
>>>>> this is
>>>>> a different story....
>>>>>
>>>>
>>>> More on the Javadoc story:
>>>>
>>>> http://stackoverflow.com/questions/32949268/how-to-exclude-a-single-module-from-javadoc-generation-in-a-maven-multi-module-p
>>>>
>>>> Reasons to exclude a module from Javadoc generation:
>>>> - The multi module project is a collection of utility libraries. One
>>>> module is a showcase to demonstrate the libraries. The Javadoc for the
>>>> showcase module is not of interest for the users of the utility
>>>> libraries.
>>>> - There are two modules foo-module and foo-module-new, where foo
>>>> module-new is a replacement of foo-module for newer projects. These
>>>> actually use the same classes and package names, excludePackageNames
>>>> in
>>>> the
>>>> Maven Javadoc plugin won't work.
>>>> - Another use case I found googling this: Not generating Javadoc for
>>>> internal APIs to the customer:
>>>>
>>>> http://maven.40175.n5.nabble.com/How-to-generate-javadocs-for-only-some-projects-in-a-multiproject-td4290609.html
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> - 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>
>>>>>>
>>>>>>
>>>>>
>>>>> I don't understand why you need such thing (like different
>>>>> directory?)
>>>>> and what is the reason for creating this kind of profile ? What is
>>>>> the
>>>>> real
>>>>> problem behind this?
>>>>>
>>>>> When the project is open in Eclipse, Eclipse will build it
>>>> automatically.
>>>> This can interfere with doing a clean build on the command line, for
>>>> example when doing a release. So we often use this profile that sets
>>>> the
>>>> target directory to somewhere else, where there's no interference from
>>>> Eclipse.
>>>>
>>>> Best regards,
>>>> Arend
>>>>
>>>>
>>>>
>>>>> Kind regards
>>>>> Karl Heinz Marbaise
>>>>>
>>>>>
>>>>>
>>>>> </profile>
>>>>>
>>>>>> </profiles>
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Arend
>>>>>>
>>>>>>
>>>>>> On Sat, Nov 14, 2015 at 2:20 PM, Karl Heinz Marbaise <
>>>>>> khmarbaise@gmx.de
>>>>>> <ma...@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-unsubscribe@maven.apache.org
>>>>>> <ma...@maven.apache.org>
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>> <ma...@maven.apache.org>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Please reopen MNG-4533 Add an always active profile activator
Posted by "Arend v. Reinersdorff" <ar...@arendvr.com>.
Hi,
yes, this is only about build time profiles. Including modules is only
relevant during build time. And I assume the profile of a dependency cannot
change the main project's target directory. So for this use case it's
irrelevant whether the profiles would be active or not active during
consume time. The profiles wouldn't have any effect at consume time anyway.
Interesting to now that file-based activation is not used during consume
time. Makes a lot of sense. Do you know if this is documented anywhere?
Best regards,
Arend
On Mon, Nov 23, 2015 at 11:08 PM, Robert Scholte <rf...@apache.org>
wrote:
> Hi,
>
> One other thing that comes to my mind: is this a build/site time profile
> or also a "consume"-time profile.
> With the latter I mean: should the profile have any effect when its
> artifact is used as a dependency?
> I think the answer is 'no', which means that the profile shouldn't always
> be active.
> File-based activation of profiles is also used only during build/site
> time, so your workaround seems quite valid to me.
>
> regards,
> Robert
>
> Op Mon, 23 Nov 2015 16:33:17 +0100 schreef Arend v. Reinersdorff <
> arend@arendvr.com>:
>
>
> Hi,
>>
>> it seems there are no more questions about the use case.
>>
>> So I'd like to return to my original request:
>> Could issue MNG-4533 "Add an always active profile activator" please be
>> reopened?
>> https://issues.apache.org/jira/browse/MNG-4533
>>
>> Best regards,
>> Arend
>>
>>
>> On Sun, Nov 15, 2015 at 1:44 PM, Arend v. Reinersdorff <arend@arendvr.com
>> >
>> wrote:
>>
>> On Sat, Nov 14, 2015 at 11:02 PM, Karl Heinz Marbaise <kh...@gmx.de>
>>> wrote:
>>>
>>> Hi,
>>>>
>>>> On 11/14/15 10:06 PM, Arend v. Reinersdorff 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,
>>>>>
>>>>>
>>>>
>>>> Ok...starting with Maven 3.2.1[1] you can use things like this:
>>>>
>>>>
>>>> mvn -pl !moduleYouDontLikeToBuild package
>>>>
>>>> So no need for a profile...I'm just quoting the answers which already
>>>> given on SO...
>>>>
>>>> Yes, that's the solution I use at the moment. Problems:
>>> 1) I think mvn -Pjavadoc would be much nicer and cleaner than mvn -pl
>>> !data-foo !data-bar javadoc:aggregate
>>> 2) I think this is OK for two modules, but using this to exclude three or
>>> more modules would be too ugly.
>>>
>>> Apart from that if you have tests which run long you should think if
>>> those
>>>
>>>> tests are really unit- or integration tests...which means different life
>>>> cycle phases etc. and never activate/deactivate modules via profiles[2]
>>>>
>>>>
>>>> [1]: http://maven.apache.org/docs/3.2.1/release-notes.html
>>>> [2]:
>>>>
>>>> http://blog.soebes.de/blog/2013/11/09/why-is-it-bad-to-activate-slash-deactive-modules-by-profiles-in-maven/
>>>>
>>>> The blog post you link in [2] correctly points out the problem with
>>> using
>>> modules in profiles: Which is that someone might forget to activate the
>>> profile, for example when doing a release. The conclusion of the blog
>>> post
>>> is to not use modules in profiles. That's where I disagree. I think using
>>> modules in profiles can be OK if the profile is always activated unless
>>> deactivated by default.
>>>
>>>
>>> >
>>>> I was researching it to exclude modules from Javadoc
>>>>
>>>> generation) The modules are excluded with "mvn -!Pfull-build"
>>>>>
>>>>>
>>>> The above can also be applied to exclude from JavaDoc ...I'm asking
>>>> myself why you like to exclude a module from JavaDoc generation but
>>>> this is
>>>> a different story....
>>>>
>>>
>>> More on the Javadoc story:
>>>
>>> http://stackoverflow.com/questions/32949268/how-to-exclude-a-single-module-from-javadoc-generation-in-a-maven-multi-module-p
>>>
>>> Reasons to exclude a module from Javadoc generation:
>>> - The multi module project is a collection of utility libraries. One
>>> module is a showcase to demonstrate the libraries. The Javadoc for the
>>> showcase module is not of interest for the users of the utility
>>> libraries.
>>> - There are two modules foo-module and foo-module-new, where foo
>>> module-new is a replacement of foo-module for newer projects. These
>>> actually use the same classes and package names, excludePackageNames in
>>> the
>>> Maven Javadoc plugin won't work.
>>> - Another use case I found googling this: Not generating Javadoc for
>>> internal APIs to the customer:
>>>
>>> http://maven.40175.n5.nabble.com/How-to-generate-javadocs-for-only-some-projects-in-a-multiproject-td4290609.html
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> - 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>
>>>>>
>>>>>
>>>>
>>>> I don't understand why you need such thing (like different directory?)
>>>> and what is the reason for creating this kind of profile ? What is the
>>>> real
>>>> problem behind this?
>>>>
>>>> When the project is open in Eclipse, Eclipse will build it
>>> automatically.
>>> This can interfere with doing a clean build on the command line, for
>>> example when doing a release. So we often use this profile that sets the
>>> target directory to somewhere else, where there's no interference from
>>> Eclipse.
>>>
>>> Best regards,
>>> Arend
>>>
>>>
>>>
>>>> Kind regards
>>>> Karl Heinz Marbaise
>>>>
>>>>
>>>>
>>>> </profile>
>>>>
>>>>> </profiles>
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Arend
>>>>>
>>>>>
>>>>> On Sat, Nov 14, 2015 at 2:20 PM, Karl Heinz Marbaise <
>>>>> khmarbaise@gmx.de
>>>>> <ma...@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-unsubscribe@maven.apache.org
>>>>> <ma...@maven.apache.org>
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>> <ma...@maven.apache.org>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Please reopen MNG-4533 Add an always active profile activator
Posted by Robert Scholte <rf...@apache.org>.
Hi,
One other thing that comes to my mind: is this a build/site time profile
or also a "consume"-time profile.
With the latter I mean: should the profile have any effect when its
artifact is used as a dependency?
I think the answer is 'no', which means that the profile shouldn't always
be active.
File-based activation of profiles is also used only during build/site
time, so your workaround seems quite valid to me.
regards,
Robert
Op Mon, 23 Nov 2015 16:33:17 +0100 schreef Arend v. Reinersdorff
<ar...@arendvr.com>:
> Hi,
>
> it seems there are no more questions about the use case.
>
> So I'd like to return to my original request:
> Could issue MNG-4533 "Add an always active profile activator" please be
> reopened?
> https://issues.apache.org/jira/browse/MNG-4533
>
> Best regards,
> Arend
>
>
> On Sun, Nov 15, 2015 at 1:44 PM, Arend v. Reinersdorff
> <ar...@arendvr.com>
> wrote:
>
>> On Sat, Nov 14, 2015 at 11:02 PM, Karl Heinz Marbaise
>> <kh...@gmx.de>
>> wrote:
>>
>>> Hi,
>>>
>>> On 11/14/15 10:06 PM, Arend v. Reinersdorff 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,
>>>>
>>>
>>>
>>> Ok...starting with Maven 3.2.1[1] you can use things like this:
>>>
>>>
>>> mvn -pl !moduleYouDontLikeToBuild package
>>>
>>> So no need for a profile...I'm just quoting the answers which already
>>> given on SO...
>>>
>> Yes, that's the solution I use at the moment. Problems:
>> 1) I think mvn -Pjavadoc would be much nicer and cleaner than mvn -pl
>> !data-foo !data-bar javadoc:aggregate
>> 2) I think this is OK for two modules, but using this to exclude three
>> or
>> more modules would be too ugly.
>>
>> Apart from that if you have tests which run long you should think if
>> those
>>> tests are really unit- or integration tests...which means different
>>> life
>>> cycle phases etc. and never activate/deactivate modules via profiles[2]
>>>
>>>
>>> [1]: http://maven.apache.org/docs/3.2.1/release-notes.html
>>> [2]:
>>> http://blog.soebes.de/blog/2013/11/09/why-is-it-bad-to-activate-slash-deactive-modules-by-profiles-in-maven/
>>>
>> The blog post you link in [2] correctly points out the problem with
>> using
>> modules in profiles: Which is that someone might forget to activate the
>> profile, for example when doing a release. The conclusion of the blog
>> post
>> is to not use modules in profiles. That's where I disagree. I think
>> using
>> modules in profiles can be OK if the profile is always activated unless
>> deactivated by default.
>>
>>
>>> >
>>> I was researching it to exclude modules from Javadoc
>>>
>>>> generation) The modules are excluded with "mvn -!Pfull-build"
>>>>
>>>
>>> The above can also be applied to exclude from JavaDoc ...I'm asking
>>> myself why you like to exclude a module from JavaDoc generation but
>>> this is
>>> a different story....
>>
>> More on the Javadoc story:
>> http://stackoverflow.com/questions/32949268/how-to-exclude-a-single-module-from-javadoc-generation-in-a-maven-multi-module-p
>>
>> Reasons to exclude a module from Javadoc generation:
>> - The multi module project is a collection of utility libraries. One
>> module is a showcase to demonstrate the libraries. The Javadoc for the
>> showcase module is not of interest for the users of the utility
>> libraries.
>> - There are two modules foo-module and foo-module-new, where foo
>> module-new is a replacement of foo-module for newer projects. These
>> actually use the same classes and package names, excludePackageNames in
>> the
>> Maven Javadoc plugin won't work.
>> - Another use case I found googling this: Not generating Javadoc for
>> internal APIs to the customer:
>> http://maven.40175.n5.nabble.com/How-to-generate-javadocs-for-only-some-projects-in-a-multiproject-td4290609.html
>>
>>
>>
>>>
>>>
>>>
>>> - 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>
>>>>
>>>
>>>
>>> I don't understand why you need such thing (like different directory?)
>>> and what is the reason for creating this kind of profile ? What is the
>>> real
>>> problem behind this?
>>>
>> When the project is open in Eclipse, Eclipse will build it
>> automatically.
>> This can interfere with doing a clean build on the command line, for
>> example when doing a release. So we often use this profile that sets the
>> target directory to somewhere else, where there's no interference from
>> Eclipse.
>>
>> Best regards,
>> Arend
>>
>>
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>>
>>>
>>> </profile>
>>>> </profiles>
>>>>
>>>>
>>>> Best regards,
>>>> Arend
>>>>
>>>>
>>>> On Sat, Nov 14, 2015 at 2:20 PM, Karl Heinz Marbaise
>>>> <khmarbaise@gmx.de
>>>> <ma...@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-unsubscribe@maven.apache.org
>>>> <ma...@maven.apache.org>
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>> <ma...@maven.apache.org>
>>>>
>>>>
>>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Please reopen MNG-4533 Add an always active profile activator
Posted by "Arend v. Reinersdorff" <ar...@arendvr.com>.
Hi,
it seems there are no more questions about the use case.
So I'd like to return to my original request:
Could issue MNG-4533 "Add an always active profile activator" please be
reopened?
https://issues.apache.org/jira/browse/MNG-4533
Best regards,
Arend
On Sun, Nov 15, 2015 at 1:44 PM, Arend v. Reinersdorff <ar...@arendvr.com>
wrote:
> On Sat, Nov 14, 2015 at 11:02 PM, Karl Heinz Marbaise <kh...@gmx.de>
> wrote:
>
>> Hi,
>>
>> On 11/14/15 10:06 PM, Arend v. Reinersdorff 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,
>>>
>>
>>
>> Ok...starting with Maven 3.2.1[1] you can use things like this:
>>
>>
>> mvn -pl !moduleYouDontLikeToBuild package
>>
>> So no need for a profile...I'm just quoting the answers which already
>> given on SO...
>>
> Yes, that's the solution I use at the moment. Problems:
> 1) I think mvn -Pjavadoc would be much nicer and cleaner than mvn -pl
> !data-foo !data-bar javadoc:aggregate
> 2) I think this is OK for two modules, but using this to exclude three or
> more modules would be too ugly.
>
> Apart from that if you have tests which run long you should think if those
>> tests are really unit- or integration tests...which means different life
>> cycle phases etc. and never activate/deactivate modules via profiles[2]
>>
>>
>> [1]: http://maven.apache.org/docs/3.2.1/release-notes.html
>> [2]:
>> http://blog.soebes.de/blog/2013/11/09/why-is-it-bad-to-activate-slash-deactive-modules-by-profiles-in-maven/
>>
> The blog post you link in [2] correctly points out the problem with using
> modules in profiles: Which is that someone might forget to activate the
> profile, for example when doing a release. The conclusion of the blog post
> is to not use modules in profiles. That's where I disagree. I think using
> modules in profiles can be OK if the profile is always activated unless
> deactivated by default.
>
>
>> >
>> I was researching it to exclude modules from Javadoc
>>
>>> generation) The modules are excluded with "mvn -!Pfull-build"
>>>
>>
>> The above can also be applied to exclude from JavaDoc ...I'm asking
>> myself why you like to exclude a module from JavaDoc generation but this is
>> a different story....
>
> More on the Javadoc story:
> http://stackoverflow.com/questions/32949268/how-to-exclude-a-single-module-from-javadoc-generation-in-a-maven-multi-module-p
>
> Reasons to exclude a module from Javadoc generation:
> - The multi module project is a collection of utility libraries. One
> module is a showcase to demonstrate the libraries. The Javadoc for the
> showcase module is not of interest for the users of the utility libraries.
> - There are two modules foo-module and foo-module-new, where foo
> module-new is a replacement of foo-module for newer projects. These
> actually use the same classes and package names, excludePackageNames in the
> Maven Javadoc plugin won't work.
> - Another use case I found googling this: Not generating Javadoc for
> internal APIs to the customer:
> http://maven.40175.n5.nabble.com/How-to-generate-javadocs-for-only-some-projects-in-a-multiproject-td4290609.html
>
>
>
>>
>>
>>
>> - 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>
>>>
>>
>>
>> I don't understand why you need such thing (like different directory?)
>> and what is the reason for creating this kind of profile ? What is the real
>> problem behind this?
>>
> When the project is open in Eclipse, Eclipse will build it automatically.
> This can interfere with doing a clean build on the command line, for
> example when doing a release. So we often use this profile that sets the
> target directory to somewhere else, where there's no interference from
> Eclipse.
>
> Best regards,
> Arend
>
>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>>
>>
>> </profile>
>>> </profiles>
>>>
>>>
>>> Best regards,
>>> Arend
>>>
>>>
>>> On Sat, Nov 14, 2015 at 2:20 PM, Karl Heinz Marbaise <khmarbaise@gmx.de
>>> <ma...@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-unsubscribe@maven.apache.org
>>> <ma...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>> <ma...@maven.apache.org>
>>>
>>>
>>>
>>
>
Re: Please reopen MNG-4533 Add an always active profile activator
Posted by "Arend v. Reinersdorff" <ar...@arendvr.com>.
On Sat, Nov 14, 2015 at 11:02 PM, Karl Heinz Marbaise <kh...@gmx.de>
wrote:
> Hi,
>
> On 11/14/15 10:06 PM, Arend v. Reinersdorff 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,
>>
>
>
> Ok...starting with Maven 3.2.1[1] you can use things like this:
>
>
> mvn -pl !moduleYouDontLikeToBuild package
>
> So no need for a profile...I'm just quoting the answers which already
> given on SO...
>
Yes, that's the solution I use at the moment. Problems:
1) I think mvn -Pjavadoc would be much nicer and cleaner than mvn -pl
!data-foo !data-bar javadoc:aggregate
2) I think this is OK for two modules, but using this to exclude three or
more modules would be too ugly.
Apart from that if you have tests which run long you should think if those
> tests are really unit- or integration tests...which means different life
> cycle phases etc. and never activate/deactivate modules via profiles[2]
>
>
> [1]: http://maven.apache.org/docs/3.2.1/release-notes.html
> [2]:
> http://blog.soebes.de/blog/2013/11/09/why-is-it-bad-to-activate-slash-deactive-modules-by-profiles-in-maven/
>
The blog post you link in [2] correctly points out the problem with using
modules in profiles: Which is that someone might forget to activate the
profile, for example when doing a release. The conclusion of the blog post
is to not use modules in profiles. That's where I disagree. I think using
modules in profiles can be OK if the profile is always activated unless
deactivated by default.
> >
> I was researching it to exclude modules from Javadoc
>
>> generation) The modules are excluded with "mvn -!Pfull-build"
>>
>
> The above can also be applied to exclude from JavaDoc ...I'm asking myself
> why you like to exclude a module from JavaDoc generation but this is a
> different story....
More on the Javadoc story:
http://stackoverflow.com/questions/32949268/how-to-exclude-a-single-module-from-javadoc-generation-in-a-maven-multi-module-p
Reasons to exclude a module from Javadoc generation:
- The multi module project is a collection of utility libraries. One module
is a showcase to demonstrate the libraries. The Javadoc for the showcase
module is not of interest for the users of the utility libraries.
- There are two modules foo-module and foo-module-new, where foo module-new
is a replacement of foo-module for newer projects. These actually use the
same classes and package names, excludePackageNames in the Maven Javadoc
plugin won't work.
- Another use case I found googling this: Not generating Javadoc for
internal APIs to the customer:
http://maven.40175.n5.nabble.com/How-to-generate-javadocs-for-only-some-projects-in-a-multiproject-td4290609.html
>
>
>
> - 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>
>>
>
>
> I don't understand why you need such thing (like different directory?) and
> what is the reason for creating this kind of profile ? What is the real
> problem behind this?
>
When the project is open in Eclipse, Eclipse will build it automatically.
This can interfere with doing a clean build on the command line, for
example when doing a release. So we often use this profile that sets the
target directory to somewhere else, where there's no interference from
Eclipse.
Best regards,
Arend
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> </profile>
>> </profiles>
>>
>>
>> Best regards,
>> Arend
>>
>>
>> On Sat, Nov 14, 2015 at 2:20 PM, Karl Heinz Marbaise <khmarbaise@gmx.de
>> <ma...@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-unsubscribe@maven.apache.org
>> <ma...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>> <ma...@maven.apache.org>
>>
>>
>>
>
Re: Please reopen MNG-4533 Add an always active profile activator
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 11/14/15 10:06 PM, Arend v. Reinersdorff 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,
Ok...starting with Maven 3.2.1[1] you can use things like this:
mvn -pl !moduleYouDontLikeToBuild package
So no need for a profile...I'm just quoting the answers which already
given on SO...
Apart from that if you have tests which run long you should think if
those tests are really unit- or integration tests...which means
different life cycle phases etc. and never activate/deactivate modules
via profiles[2]
[1]: http://maven.apache.org/docs/3.2.1/release-notes.html
[2]:
http://blog.soebes.de/blog/2013/11/09/why-is-it-bad-to-activate-slash-deactive-modules-by-profiles-in-maven/
>
I was researching it to exclude modules from Javadoc
> generation) The modules are excluded with "mvn -!Pfull-build"
The above can also be applied to exclude from JavaDoc ...I'm asking
myself why you like to exclude a module from JavaDoc generation but this
is a different story....
> - 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>
I don't understand why you need such thing (like different directory?)
and what is the reason for creating this kind of profile ? What is the
real problem behind this?
Kind regards
Karl Heinz Marbaise
> </profile>
> </profiles>
>
>
> Best regards,
> Arend
>
>
> On Sat, Nov 14, 2015 at 2:20 PM, Karl Heinz Marbaise <khmarbaise@gmx.de
> <ma...@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-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Please reopen MNG-4533 Add an always active profile activator
Posted by "Arend v. Reinersdorff" <ar...@arendvr.com>.
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 <ct...@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 <kh...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
Re: Please reopen MNG-4533 Add an always active profile activator
Posted by Curtis Rueden <ct...@wisc.edu>.
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 <kh...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: Please reopen MNG-4533 Add an always active profile activator
Posted by "Arend v. Reinersdorff" <ar...@arendvr.com>.
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 <kh...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Please reopen MNG-4533 Add an always active profile activator
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org