On Sat, Nov 14, 2015 at 11:02 PM, Karl Heinz Marbaise
<khmarba...@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
<khmarba...@gmx.de
<mailto: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
<mailto:users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
<mailto:users-h...@maven.apache.org>
