maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: Please reopen MNG-4533 Add an always active profile activator
Date Mon, 23 Nov 2015 22:08:55 GMT
Hi,

One other thing that comes to my mind: is this a build/site time profile  
or also a "consume"-time profile.
With the latter I mean: should the profile have any effect when its  
artifact is used as a dependency?
I think the answer is 'no', which means that the profile shouldn't always  
be active.
File-based activation of profiles is also used only during build/site  
time, so your workaround seems quite valid to me.

regards,
Robert

Op Mon, 23 Nov 2015 16:33:17 +0100 schreef Arend v. Reinersdorff  
<arend@arendvr.com>:

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message