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 <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> >>> >>> >>> >> >
