Question

在我们的基础架构中，我们有许多由Maven2构建的小型Java项目。每个项目都有自己的pom.xml，最终继承自我们的公司“master”父母pom。

我们最近开始向我们的父pom添加小配置文件，默认情况下禁用，启用后，以常规方式执行单个插件。

示例：

' 来源 '个人资料执行 maven-source-plugin 以创建项目源包。
“ clover ”配置文件执行 maven-clover2-plugin 以生成Clover报告。它还嵌入了我们的Clover许可证文件，因此无需在子项目中重新指定。
' fitnesse '配置文件执行 fitnesse-maven-plugin 以运行与项目相关的fitnesse测试。它包含fitnesse服务器主机和端口以及其他不需要重复的信息。

这用于在我们的CI服务器中指定构建，如：

mvn test -P clover
mvn deploy site-deploy -P fitnesse,sources

等等。

到目前为止，这似乎提供了一个方便的可选功能组合。

然而，继续采用这种方法（明显或其他方面）是否有任何危险或陷阱？这种功能可以更好地实现或以其他方式表达吗？

Answer 1

此解决方案的问题在于您可能正在创建一个“挑选”模型，这种模型有点不可能。对于您描述的配置文件，您介于两者之间;如果每个配置文件本身产生一个不错的结果，你可能没问题。当你开始需要特定的配置文件组合时，我认为你正在走向麻烦。

个别开发人员通常会遇到一致性问题，因为他们忘记了应该为给定方案使用哪组配置文件。您的里程可能会有所不同，但我们遇到了实际问题。一半的开发人员会在很短的时间内忘记“正确的”组合，并最终定期浪费小时，因为他们在错误的时间运行错误的组合。

您将遇到的实际问题是，AFAIK无法拥有一组激活一组子配置文件的“元”配置文件。如果有一个很好的方法来创建一个伞形配置文件，这将是一个非常简洁的功能。您的“fitnesse”和“来源”配置文件应该是私有的，由一个或多个元配置文件激活。（您可以激活每个开发人员的settings.xml中的默认设置）

Answer 2

在Maven中拥有多个配置文件没有问题，实际上我认为它们是允许您的构建启用和禁用功能类的绝佳方式。我建议根据它们的功能而不是插件来命名它们，并考虑在同一个配置文件中对功能相关的插件进行分组。

作为您遵循的先例，Maven super POM定义了“发布配置文件”，其中包括source，javadoc和deploy插件的配置。

您应该考虑采用这种方法，因此您的“fitnesse”配置文件将成为“集成测试”，您可以选择在以后需要时在该配置文件中定义其他插件。同样，“三叶草”配置文件可以重命名为“网站”，您可以在该配置文件中定义其他报告，例如JDepend，JXR，PMD插件的配置。

Answer 3

你似乎对这种方法略显怀疑，但你不确定为什么 - 毕竟，它非常方便。无论如何，这就是我对它的看法：我不知道为什么，但它似乎有点奇怪。

让我们考虑这两个问题： a）什么是配置文件意味着什么？ b）我们应该采用哪种替代方法来比较你的方法？

关于a），我认为配置文件适用于不同的构建或执行环境。您可能依赖于本地安装的软件，您可以使用配置文件在相应环境中定义可执行文件的路径。或者您可能具有不同运行时配置的配置文件，例如“开发”，“测试”，“生产”。有关详细信息，请参见http://maven.apache.org/guides/mini/guide-building-for-different-environments.html和http://maven.apache.org/guides/introduction/introduction-to-profiles.html。

至于b），我想到的想法：

使用命令行属性触发插件。如mvn -Dfitnesse = true deploy。就像众所周知的-ddownloadSources = true表示eclipse插件，或-Dmaven.test.skip = true表示肯定。但这需要插件有一个标志来触发执行。并非您需要的所有插件都可能具有此功能。
明确地调用目标。你可以在一个命令行上调用几个目标，比如“mvn clean package war：explosion”。当fitnesse自动执行时（使用相应的配置文件），这意味着它的执行被绑定到生命周期阶段。也就是说，只要达到生命周期中的那个阶段，就会执行插件。您应该能够包含插件，而不是将插件执行绑定到生命周期阶段，而只能在显式调用时执行它。所以你的电话看起来像“mvn fitnesse：run source：jar deploy”。

问题a）的答案可能解释了“奇怪”。这不是什么配置文件的意思。

因此，我认为备选方案2实际上可能是更好的方法。当不同执行或构建环境的“真实”配置文件发挥作用时，使用配置文件可能会成为问题。你最终会得到一个可能混淆的配置文件混合，其中配置文件意味着非常不同的东西（例如“test”表示环境，而“fitnesse”表示目标）。如果您只是明确地调用目标，我认为这将是非常明确和灵活的。记住插件/目标名称应该比记住配置文件名称更困难。

Maven中有很多继承的单插件配置文件是个好主意吗？

3 个答案: