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

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.

These files are involved in the activation process.

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.

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

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.

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

Try: <activeByDefault>true</activeByDefault> instead

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.

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?

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>

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.

File with a fix that replaces all instanceof ${basedir} with the foldername of the pom file is attached.

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

Fixed in r788334. Relative paths and paths starting with {{${basedir}}} are now resolved relative to the currently built project.

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

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

Works for inherited profiles in Maven 3 only.