Maven
  1. Maven
  2. MNG-2363

<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

          Activity

          Hide
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
            • Votes:
              19 Vote for this issue
              Watchers:
              28 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: