为了扩展@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>
并older
自动激活配置文件。如果默认情况下未激活,您可以使用基于文件的激活来使此模块针对 1.1 构建newest
,但是暂时针对 2.0 运行它并不容易:据我所知,如果您通过了,older
并且newest
配置文件都将处于活动状态-Pnewest
,所以您需要明确禁用其他配置文件,如果您有十几个配置文件,这是不合理的。因此,除了将配置文件信息复制到子 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浮现在脑海中。