如何管理代码生成器等项目支持工具的依存关系？

Question

从来没有找到一个真正令人满意的解决方案。你怎么做呢？我正在寻找新方法的灵感。

对于上下文，假设我编写了一个生成器，该生成器使用项目资源并生成代码文件。但这可以是任何其他项目支持工具-验证程序，转换器，部署程序等。通常是手动触发的操作，这些操作不作为正常构建的一部分运行。

这类工具通常需要一些依赖项，而这些依赖项在运行时项目本身并不需要。

我过去应用或考虑过的策略：

• 无论如何都将工具依赖项添加到项目中，并在打包过程中将其标记为“提供”或将其过滤掉（这是我通常要做的，但是现在我有添加使用工具依赖项的常规项目代码的危险，可能会导致错误仅在运行时出现）
• 使用脚本（尽量避免使用脚本及其隐藏的依赖关系和复杂性）
• 创建单独的支持项目（努力避免项目爆炸，尤其是对于由几行代码处理的看似小的任务而言）
• 子项目/模块（只是模糊地意识到此选项，从未真正尝试过）
• 与带有独立依赖项的配置文件一起运行的maven插件（试图避免维护自定义插件所需的单独项目）

答案和评论的启发

• 由多个项目共享的单独工具项目

Answer 1

我刚刚意识到maven和eclipse已经针对一个非常特定的“工具”（测试代码）完全解决了这个问题。

测试代码通常需要应用程序本身未使用的其他依赖项。

与创建一个单独的测试项目相反，人们显然投入了很多钱来将“测试/工具”基础结构保留在同一项目中：

• 单独的源位置（src / main / java，src / test / java）
• 单独的资源位置（src / main / resources，src / test / resources）
• 成熟的独立Maven依赖范围“测试”，具有传递性解析
• 具有单独的依赖关系树的单独的编译阶段（编译/测试）
• eclipse支持特殊的junit启动配置，这些配置可以正确解决测试依赖项
• 我目前不知道的更多东西

因此，我强烈考虑将所有支持工具编程为“ junit测试用例”。

我打算为仅执行一个特定“测试用例”的团队创建并提交共享的junit启动配置，这将运行工具逻辑而不是进行测试。

我要解决的问题是避免在常规Maven测试阶段运行这些虚拟测试。

同样，我在写这篇文章时意识到，已经有另一个这样的系统：maven插件基础结构，它也具有单独的依赖项解析机制。尽管到目前为止，创建单独的项目来创建插件似乎是必要或正常的。我将研究编写和构建项目特定的maven插件的方法，而无需创建单独的项目。我正在考虑即时生成插件编译所需的pom.xml，并包括所有测试依赖项。