更新

Question

我的应用程序中的Ant构建文件有以下层次结构：

Application
|---MainProject
|       |__ build.xml
|
|---Project1
|       |__ build.xml
|
|---Project2
       |__ build.xml

Ant目标根据其任务分配如下：

1）MainProject构建文件对所有其他构建文件的ant目标进行clean次调用

2）所有项目中的JUnit测试都是在MainProject构建文件中使用其中包含junit任务的公共junit目标执行的。

3）其他构建文件中的所有其他任务都是通过ant调用所有其他文件中的build-project目标来执行的。

4）构建项目目标进一步决定了各个文件中要执行的任务。

这个架构对你来说如何？对于这种情况，您的方法是什么？建议的方法是什么？

Answer 1

这将是ANT中一个相当典型的多模块构建场景，随着时间的推移，它会导致相当典型的大型单片项目构建....

我建议考虑Maven如何构建它的多模块项目。您希望模拟Maven的“本地存储”概念，即每个模块推送其构建的工件的位置。永远不要共享类路径，而是每个“build.xml”文件根据本地仓库中的文件创建它们：

<path id="compile.path">
    <fileset dir="${local.repo.containing.built.jars}" includes="*.jar"/>
    <fileset dir="${dir.containing.third.party.jars}" includes="*.jar"/>
</path>

好处

每个子模块都可以独立的方式构建（在开发期间），而不必强制完整整个项目的重建。
您的第三方依赖关系在您的类路径中明显不同

随着项目的发展，你需要意识到模块之间的相互依赖性。使用少量子模块，构建顺序很明显，但随着时间的推移，子模块可能会依赖于首先构建的许多其他子模块。

最后，apache ivy项目提供了一些工具，可以在您的ANT构建中添加类似Maven的功能。有一个multi-module例子，然而，我发现作为初学者很难理解。我会把它放在你的积压上，考虑将来将子模块工件发布到像Nexus这样的Maven存储库中。这将使您的ANT构建与使用Maven和Gradle等替代构建技术的其他团队兼容。

更新

ivy simple shared repository

从JUnit单元测试角度看Java EE应用程序中的Ant构建文件中的任务的层次结构和分布

1 个答案:

更新