views:

1054

answers:

4

We have a multi module build with modules using different technologies, like Java and Flex. Is it somehow possible to activate different profiles based on the module that is compiled currently?

I tried it with an activation like

<profile>
  <id>flex</id>
  <activation>
    <file>
      <exists>${basedir}/src/main/flex</exists>
    </file>
  </activation>
  ...
</profile

But it didn't work, although the use of ${basedir} is documented in the Maven documentation (this is a bug in Maven). Is there a different possibility to have different activations based on the current module? Or does Maven only allow to activate a profile for all modules or not at all?

A: 

You can set a property in each module that you want to use the profile, and then use "property" activation in your profiles.

Clay
Does not work here. I defined a profile in a parent with a "property" activation and used the <property> section to defined that property to the respective value to activate the profile. The profile is not activated. Even in case I specify the property with mvn -Dproperty=value. The last works only in case I run it on the parent. Seems like the property must in fact be a system property specified through the -D option and profiles are not inherited at all, which makes this useless for me :-(
Yaba
A: 

After some more research I finally came to the conclusion that this is not possible for two reasons in the current Maven version (2.1.0):

  • Maven profiles are not inherited, so you can't define a profile in a parent POM and activate that in a child POM.
  • I haven't found a possibility to activate a profile from a POM itself. The activation does not work with ${basedir} and the property activation response only to system settings, which are globally specified through the -D option.
Yaba
A: 

With regard to file-based activation, you can try removing ${basedir}. We use it like this:

<activation>
   <file>
      <missing>target/jboss/conf/jboss-service.xml</missing>
   </file>
</activation>
Does not work, as with this notation it looks just once at the specified file relative to the parent POM location and does not do it for child POMs again.
Yaba
A: 

In 2.2.1, profiles are inherited but the ${basedir} issue is still there. I'm in the same boat - I need to activate a profile based on the existence of a file in a given project. My child builds run individually just fine (inherited profile activated by local file existance), but if I run the build from the top parent, they fail because the file isn't found.

Patrick Aikens