在@rich-seller的答案和@Bostone的自答的基础上,似乎不可能设置父POM定义几个替代配置文件,而子POM默认选择其中一个配置文件,并允许您临时覆盖子项的选择(即在CLI上)。 考虑一个用于项目使用某种框架和关联插件的父POM,我们可以假定这些版本都由属性定义:
<profiles>
<profile>
<id>newest</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<framework.version>2.0</framework.version>
<plugin.version>2.0</plugin.version>
</properties>
</profile>
<profile>
<id>older</id>
<activation>
<property>
<name>older.framework</name>
<value>true</value>
</property>
</activation>
<properties>
<framework.version>1.1</framework.version>
<plugin.version>1.1</plugin.version>
</properties>
</profile>
</profiles>
现在,一个从这个父POM继承的子模块默认会使用2.0,就像你所期望的那样,-Polder
或-Dolder.framework=true
可以用来尝试使用旧框架进行构建(例如测试兼容性)。然而,在子模块的POM文件中你不能进行编写。
<properties>
<older.framework>true</older.framework>
</properties>
可以通过将配置信息复制到子POM中实现自动激活older
配置文件。如果newest
不是默认激活的,您可以使用基于文件的激活来使此模块构建针对1.1版本,但是这样就不容易暂时将其运行针对2.0版本:据我所知,如果您传递-Pnewest
,则两个older
和newest
配置文件都将处于活动状态,因此您需要明确地禁用其他配置文件,如果您有十几个配置文件,则这是不合理的。因此,除了将配置信息复制到子POM中,没有其他解决方案:
<properties>
<framework.version>1.1</framework.version>
<plugin.version>1.1</plugin.version>
</properties>
这时候使用-Pnewest
将无法覆盖这些属性,所以你需要使用-Dframework.version=2.0 -Dplugin.version=2.0
。
换句话说,只有当所有子模块默认都能使用相同的配置文件(此处为newest
)时,配置文件才有用。如果其中一些子模块通常使用1.1版本,而其他的则使用2.0版本,则配置文件就没用了。
似乎这是Maven核心增强或Maven 3构建扩展的用例。http://docs.codehaus.org/display/MAVEN/Custom+Profile+Activators和https://github.com/maoo/maven-tiles看起来不错。