maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arend v. Reinersdorff" <ar...@arendvr.com>
Subject Re: Please reopen MNG-4533 Add an always active profile activator
Date Mon, 23 Nov 2015 15:33:17 GMT
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 <khmarbaise@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
>>> <mailto:khmarbaise@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
>>>     <mailto:users-unsubscribe@maven.apache.org>
>>>     For additional commands, e-mail: users-help@maven.apache.org
>>>     <mailto:users-help@maven.apache.org>
>>>
>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message