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

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"文件根据本地repo中的文件创建它们:

<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项目提供了将类似maven的特性添加到ANT构建中的工具。有一个多模块的例子，然而，我发现它很难理解作为一个初学者。我会把它放在您的backlog中，并考虑将来将子模块工件发布到像Nexus这样的Maven存储库中。这将使您的ANT构建与使用替代构建技术(如Maven和Gradle)的其他团队兼容。

<标题> 更新

• ivy简单共享存储库