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 Tue, 24 Nov 2015 10:23:40 GMT
Hi,

yes, this is only about build time profiles. Including modules is only
relevant during build time. And I assume the profile of a dependency cannot
change the main project's target directory. So for this use case it's
irrelevant whether the profiles would be active or not active during
consume time. The profiles wouldn't have any effect at consume time anyway.

Interesting to now that file-based activation is not used during consume
time. Makes a lot of sense. Do you know if this is documented anywhere?

Best regards,
Arend


On Mon, Nov 23, 2015 at 11:08 PM, Robert Scholte <rfscholte@apache.org>
wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message