Maven 2 & 3

<profile><activation><file><exists/> does not work in a multi-project build

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 3.0-alpha-3
  • Component/s: Profiles
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    5

Description

I would expect each subproject to have the profile turned on or off depending on whether ${basedir}/file-to-check-for exists.

Instead, during a multi-project build the profile is either on or off depending on whether the file exists relative to the aggregator pom. The decision is made once.

Variable substitution doesn't work, so I can't explicitly use <exists>${basedir}/file-to-check-for</exists> or any variation on this theme to workaround the bug.

Some background to my particular problem. I have 10 modules to build. Some of them are GUI modules and contain a file called plugin.xml in the subproject directory. I want to package these up specially and sign them, ready for deployment to webstart. The other modules are shared and server code and I don't want these packaged in the same way. So, I've got a dependency in my parent pom file which activates a profile called "guibundle" if a plugin.xml file exists in the subproject directory.

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MNG-1775 No property expansion in profile activation

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-3017 Profile activation by file fails when maven is run outside the pom's directory

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-3524 Profile to be activated when file is missing is always activated

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-4120 Profile activation should be per module

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-4174 Inheritance from profiles from parent-pom to child-pom

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-4620 Reporting profiles not executed in child modules.

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. MNG-3140 add support for ${basedir} property in profile activation

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-5360 profile/activation/file does not work with ${project.basedir}, only with ${basedir}

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MNG-4735 File-based profile activation behaves differently in Maven 3

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Boden added a comment -

Actually, not even an <activeByDefault/> causes a profile to become active during a multi-project build.

Please unzip problemactivation.zip into a directory. Then navigate into the child folder and execute:
mvn install

You will see a printout of the effective pom.

Now navigate back a directory and execute:
mvn -f pom-aggregator.xml install

You will not see a printout of the effective pom, even though the profile should have been activated.

I have also commented in the parent pom.xml that <file/> activation doesn't work either. This bug relates more to <file/> activation, but it's important to get the <activeByDefault/> working first.

Show
David Boden added a comment - Actually, not even an <activeByDefault/> causes a profile to become active during a multi-project build. Please unzip problemactivation.zip into a directory. Then navigate into the child folder and execute: mvn install You will see a printout of the effective pom. Now navigate back a directory and execute: mvn -f pom-aggregator.xml install You will not see a printout of the effective pom, even though the profile should have been activated. I have also commented in the parent pom.xml that <file/> activation doesn't work either. This bug relates more to <file/> activation, but it's important to get the <activeByDefault/> working first.
Hide
Permalink
David Boden added a comment -

These files are involved in the activation process.

Show
David Boden added a comment - These files are involved in the activation process.
Hide
Permalink
Ryan Slobojan added a comment -

Similar situation, similar result for us. We are trying to only activate a profile on a submodule of a reactor build, and the one-time evaluation makes this impossible.

Has a fix for this issue been implemented or considered? I see that the fix version is currently 2.1, but is that wishful thinking or will this bug actually be addressed in 2.1? We would prefer if it could be addressed in 2.0.5 if possible, in order to get a fix sooner rather than later for this issue.

Show
Ryan Slobojan added a comment - Similar situation, similar result for us. We are trying to only activate a profile on a submodule of a reactor build, and the one-time evaluation makes this impossible. Has a fix for this issue been implemented or considered? I see that the fix version is currently 2.1, but is that wishful thinking or will this bug actually be addressed in 2.1? We would prefer if it could be addressed in 2.0.5 if possible, in order to get a fix sooner rather than later for this issue.
Hide
Permalink
Franz Garsombke added a comment -

Same problem. I have a predefined ant plugin (in pluginmanagement) at the aggregator level. I do not want all of the sub modules to inherit this ant plugin since some of the sub modules need to define their own executions for the ant plugin. Creating profiles at the aggregator level and then inheriting a profile seemed like the right approach. The <file> activation does not allow me to work at the submodule level.

Thanks,

Franz

Show
Franz Garsombke added a comment - Same problem. I have a predefined ant plugin (in pluginmanagement) at the aggregator level. I do not want all of the sub modules to inherit this ant plugin since some of the sub modules need to define their own executions for the ant plugin. Creating profiles at the aggregator level and then inheriting a profile seemed like the right approach. The <file> activation does not allow me to work at the submodule level. Thanks, Franz
Hide
Permalink
Ben Tatham added a comment -

I have the same issue, but not using modules.

This is the critical point:
"Instead, during a multi-project build the profile is either on or off depending on whether the file exists relative to the aggregator pom. The decision is made once."

I want a parent pom to define some plugin executions (like xdoclet, jspc, etc), so I can reuse those plugin configurations in all my other projects that need these tools. Of course, that parent project doesn't have servlets/tags/jsps to compile, so I have to use a profile to define them so that I can actually install the pom project itself. But I don't want to have to use a command line property to turn it on...my tests rely on those plugins running.

Show
Ben Tatham added a comment - I have the same issue, but not using modules. This is the critical point: "Instead, during a multi-project build the profile is either on or off depending on whether the file exists relative to the aggregator pom. The decision is made once." I want a parent pom to define some plugin executions (like xdoclet, jspc, etc), so I can reuse those plugin configurations in all my other projects that need these tools. Of course, that parent project doesn't have servlets/tags/jsps to compile, so I have to use a profile to define them so that I can actually install the pom project itself. But I don't want to have to use a command line property to turn it on...my tests rely on those plugins running.
Hide
Permalink
Wendy Smoak added a comment -

David Boden wrote:
> Actually, not even an <activeByDefault/> causes a profile to become active during a multi-project build.

Try: <activeByDefault>true</activeByDefault> instead

Show
Wendy Smoak added a comment - David Boden wrote: > Actually, not even an <activeByDefault/> causes a profile to become active during a multi-project build. Try: <activeByDefault>true</activeByDefault> instead
Hide
Permalink
David Boden added a comment -

Hi Wendy. Yes, I agree. I wish that I could scrub my comments on <activeByDefault/>. I can confirm that <activeByDefault>true</activeByDefault> does work as expected.

Show
David Boden added a comment - Hi Wendy. Yes, I agree. I wish that I could scrub my comments on <activeByDefault/>. I can confirm that <activeByDefault>true</activeByDefault> does work as expected.
Hide
Permalink
chenliang added a comment -

I have the same issue.
I also have tried another way: to set a varible "needRun" to make sure whether the sub module need to run the profile. Buf unfortunately, the activation does not support the varible which defined in the POM. It only recognize the Command Line Varible, such : mvn -DneedRun=true

Is there any solutions?

Show
chenliang added a comment - I have the same issue. I also have tried another way: to set a varible "needRun" to make sure whether the sub module need to run the profile. Buf unfortunately, the activation does not support the varible which defined in the POM. It only recognize the Command Line Varible, such : mvn -DneedRun=true Is there any solutions?
Hide
Permalink
Karsten Tinnefeld added a comment - - edited

I stubled on this, as well (see MNG-4120).

The title is a bit short-sighted, as <activation><property> (and, of course, <activation><file><missing>) could also be module-dependent:

<project><parent><artifactId>parent</artifactId></parent>
<artifactId>project-a</artifactId>
<properties><some-property>true</some-property></properties></project>

<project><parent><artifactId>parent</artifactId></parent>
<artifactId>project-b</artifactId>
<properties><some-property>false</some-property></properties></project>

should also be selectively running a target based on a profile

<project><artifactId>parent</artifactId>
<properties><activation><property><name>some-property</name><value>true</value></property></properties>
<build><!-- project-a specific actions here --></build></project>

Show
Karsten Tinnefeld added a comment - - edited I stubled on this, as well (see MNG-4120 ). The title is a bit short-sighted, as <activation><property> (and, of course, <activation><file><missing>) could also be module-dependent: <project><parent><artifactId>parent</artifactId></parent> <artifactId>project-a</artifactId> <properties><some-property>true</some-property></properties></project> <project><parent><artifactId>parent</artifactId></parent> <artifactId>project-b</artifactId> <properties><some-property>false</some-property></properties></project> should also be selectively running a target based on a profile <project><artifactId>parent</artifactId> <properties><activation><property><name>some-property</name><value>true</value></property></properties> <build><!-- project-a specific actions here --></build></project>
Hide
Permalink
Jan Labrie added a comment -

Like probably many others we also stumbled over this issue. The combination of a multi-pom project and file based activation does not work, because properties like $

{basedir} are not expanded. This is pretty annoying because it is a common setup and there is no workaround. What also did not help was that help:effective-pom reports a pom.xml in which ${basedir}

is expanded.

I made a fix for this issue. The best solution would be that a relative filename in the activation would be evaluated in respect to the location of the pom file that contains the activation. I didn't code this, because in FileProfileActivator.java I was not able to retrieve the project or the location of the current pom file. Because of this I also could not do an expansion of $

{basedir}, because I didn't know what to replace it with. Later I read in a comment from Nicolas de Loof that the activation of profiles is calculated very early in the lifecycle, and that there is not even an active project at that moment.

So I coded a solution in the reading of the xml file. Whenever a model is read from a local file all occurences of ${basedir}

are replaced by the foldername of the pom file. This is coded in DefaultMavenProjectBuilder.readModel().

I have attached the file. It is based on trunk 2.0.x (It reports that it is 2.0.11.SNAPSHOT).

There are some remarks to be made:

  • The replacement is not done for pom files that are adressed by a URL instead of a local file.
  • The replacement is done with String.ReplaceAll(). This might be a little too rough.
Show
Jan Labrie added a comment - Like probably many others we also stumbled over this issue. The combination of a multi-pom project and file based activation does not work, because properties like $ {basedir} are not expanded. This is pretty annoying because it is a common setup and there is no workaround. What also did not help was that help:effective-pom reports a pom.xml in which ${basedir} is expanded. I made a fix for this issue. The best solution would be that a relative filename in the activation would be evaluated in respect to the location of the pom file that contains the activation. I didn't code this, because in FileProfileActivator.java I was not able to retrieve the project or the location of the current pom file. Because of this I also could not do an expansion of $ {basedir}, because I didn't know what to replace it with. Later I read in a comment from Nicolas de Loof that the activation of profiles is calculated very early in the lifecycle, and that there is not even an active project at that moment. So I coded a solution in the reading of the xml file. Whenever a model is read from a local file all occurences of ${basedir} are replaced by the foldername of the pom file. This is coded in DefaultMavenProjectBuilder.readModel(). I have attached the file. It is based on trunk 2.0.x (It reports that it is 2.0.11.SNAPSHOT). There are some remarks to be made: The replacement is not done for pom files that are adressed by a URL instead of a local file. The replacement is done with String.ReplaceAll(). This might be a little too rough.
Hide
Permalink
Jan Labrie added a comment - - edited

File with a fix that replaces all instanceof $

{basedir}

with the foldername of the pom file is attached.

Show
Jan Labrie added a comment - - edited File with a fix that replaces all instanceof $ {basedir} with the foldername of the pom file is attached.
Hide
Permalink
Jan Labrie added a comment -

Attached a fix file with a small textual update and a diff file.

Show
Jan Labrie added a comment - Attached a fix file with a small textual update and a diff file.
Hide
Permalink
Benjamin Bentmann added a comment - - edited

Fixed in r788334. Relative paths and paths starting with {{$

{basedir}

}} are now resolved relative to the currently built project.

Show
Benjamin Bentmann added a comment - - edited Fixed in r788334 . Relative paths and paths starting with {{$ {basedir} }} are now resolved relative to the currently built project.
Hide
Permalink
Denis Cabasson added a comment -

Any plan on fixing that on the 2.2.x branch as well? Having the fix in 3.0-alpha means it won't actually work before the first stable release of 3.0. I hope we could expect a quicker release of a 2.2.x version with that bug fixed. I has already a significant number of votes, and would get my life and the life of a few other people easier

Show
Denis Cabasson added a comment - Any plan on fixing that on the 2.2.x branch as well? Having the fix in 3.0-alpha means it won't actually work before the first stable release of 3.0. I hope we could expect a quicker release of a 2.2.x version with that bug fixed. I has already a significant number of votes, and would get my life and the life of a few other people easier
Hide
Permalink
David Biesack added a comment -

Can someone identify which released version (of what plugin) this is fixed?
I still see this bug (however, I do not have a multi-project config); just a pom.xml and a parent pom.
In my <profiles> in the project pom.xml I have

<profile>
<id>cobertura.off</id>
<activation>
<file>
<exists>$

{basedir}/cobertura.off</exists>
</file>
</activation>
<properties>
<skip.cobertura>true</skip.cobertura>
</properties>
</profile>
<profile>
<id>cobertura.on</id>
<activation>
<file>
<missing>${basedir}

/cobertura.off</missing>
</file>
</activation>
<properties>
<skip.cobertura>false</skip.cobertura>
</properties>
</profile>

but even if the file cobertura.off exists (same dir as pom.xml), mvn help:active-profiles shows that cobertura.on is active and cobertura.off is not active.

This does work if I use <exists>cobertura.off</exists> and <missing>cobertura.off</missing> respectively

Thus the doc at http://maven.apache.org/pom.html#Activation is (still) wrong as it shows use of $

{basedir}

/

I'm using apache-maven-2.2.1

Show
David Biesack added a comment - Can someone identify which released version (of what plugin) this is fixed? I still see this bug (however, I do not have a multi-project config); just a pom.xml and a parent pom. In my <profiles> in the project pom.xml I have <profile> <id>cobertura.off</id> <activation> <file> <exists>$ {basedir}/cobertura.off</exists> </file> </activation> <properties> <skip.cobertura>true</skip.cobertura> </properties> </profile> <profile> <id>cobertura.on</id> <activation> <file> <missing>${basedir} /cobertura.off</missing> </file> </activation> <properties> <skip.cobertura>false</skip.cobertura> </properties> </profile> but even if the file cobertura.off exists (same dir as pom.xml), mvn help:active-profiles shows that cobertura.on is active and cobertura.off is not active. This does work if I use <exists>cobertura.off</exists> and <missing>cobertura.off</missing> respectively Thus the doc at http://maven.apache.org/pom.html#Activation is (still) wrong as it shows use of $ {basedir} / I'm using apache-maven-2.2.1
Hide
Permalink
Jörg Schaible added a comment -

Works for inherited profiles in Maven 3 only.

Show
Jörg Schaible added a comment - Works for inherited profiles in Maven 3 only.
Hide
Permalink
Bill Riemers added a comment -

While this bug has been fixed, most of the bugs that are marked as duplicates of this bug have not been... As the only thing that has been fixed is the usage of $

{basedir}

. Other properties still have problems, and the documentation still does not list this limitation.

Show
Bill Riemers added a comment - While this bug has been fixed, most of the bugs that are marked as duplicates of this bug have not been... As the only thing that has been fixed is the usage of $ {basedir} . Other properties still have problems, and the documentation still does not list this limitation.
Hide
Permalink
Olivier Lamy added a comment -

doesn't work anymore with 3.0.x
see https://jira.codehaus.org/browse/MNG-5418

Show
Olivier Lamy added a comment - doesn't work anymore with 3.0.x see https://jira.codehaus.org/browse/MNG-5418

People

  • Assignee:
    Benjamin Bentmann
    Reporter:
    David Boden
Vote (19)
Watch (27)

Dates

  • Created:
    Updated:
    Resolved: