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 Sun, 15 Nov 2015 12:44:29 GMT
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