[
http://jira.codehaus.org/browse/MNG-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=180938#action_180938
]
Jan Labrie commented on MNG-2363:
---------------------------------
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.
> <profile><activation><file><exists/> does not work in a multi-project build
> ---------------------------------------------------------------------------
>
> Key: MNG-2363
> URL: http://jira.codehaus.org/browse/MNG-2363
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
> Reporter: David Boden
> Priority: Critical
> Fix For: 2.2.x
>
> Attachments: problemactivation.zip, screenshot-1.jpg
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
