避免Maven插件构建和测试之间的循环依赖

我有一个包含以下子项目的项目：

• 福科德根
  …顾名思义，它执行代码生成

• foomaven插件
  …在构建过程中调用foo codegen

一般来说，这很好用。问题是，当我想测试

foo-codegen

：

foo-maven-plugin

在foo-codegen的构建周期中还不可用，如果我们按照依赖关系的顺序进行组合，但是测试的构建过程调用该插件来实际执行必要的代码生成

---

打破这条链条的正确方法是什么？我是否应该将foo codegen的测试转移到第三个子项目中？在测试阶段使用Maven调用器插件而不是foomaven插件来生成代码？还有什么吗？

如果您先将

mvn安装

或

mvn部署

到插件上的存储库中，那么您可以按任意顺序运行它们，并单独执行

mvn编译

。

mvn安装无法在插件上进行，除非存在可用的

foo codegen

版本。更重要的是，如果插件是针对比被测版本更早的foo codegen构建的，那么当它在foo codegen构建的测试阶段使用时，它不会很好地测试代码生成。您将拥有一个或另一个可以完成第一个构建的

引导版本。也可能是plugin.Hmm的
no op
版本——我问得很糟糕
FooMaven插件
由maven在
FooCodeGen
的测试阶段使用——noop版本没有任何效果，因此会阻止测试的构建。现在，如果我可以针对一个版本的
foo-codegen构建
foo-maven插件，
，然后在
foo-codegen
测试阶段运行一个刚构建的
foo-codegen
jar，而不是它编译时所针对的版本，那将是完美的——但我不知道这是否合理，在禁用测试的情况下编译，然后分别运行测试，使用概要文件来启用和禁用所需的功能。这是一种很好的方法。不过，我不确定最终用户的难度/开销是否比将测试转移到单独的子项目更低。为什么foo codegen的测试使用foo maven插件？@Tome foo codegen的测试依赖于根据生成的代码编译类以供测试
foo maven plugin
是在构建过程中调用
foo codegen
的标准方法——使用它既是跟踪，也是向最终用户提供示例（因此，是隐式文档）。我个人会在foo codegen上使用基本单元测试，以及更完整的（通过maven invoker plugin）端到端测试（+这确实是隐含的文件）在foo maven插件内部。maven插件模块必须依赖N-1版本的codegen，这对我来说太糟糕了。发布过程如何？@Tome…好吧，将测试分离到自己的子项目中意味着没有N-1依赖关系，所以这在一定程度上解决了问题；只是在foo codegen上工作的人需要知道如何运行“mvn测试”在他们的整个foo项目上进行，而不仅仅是foo codegen子项目。是的，另一个解决方案是创建不需要依赖的测试