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 <[email protected]
<mailto:[email protected]>> 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: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
