Ant 部署而不是 Eclipse 以简化开发

Question

我在 java jars 部署方面相当菜鸟。我有以下情况： 我在 Eclipse 中有大约 6 个项目，它们有多种类型（通用接口的核心项目、包含 osgi 包的项目、带有测试的项目、带有用于 Web 部署的 servlet 的项目）。

我在快速部署任何东西方面遇到了越来越大的问题，今天我面临着 OSGi 捆绑部署，我想快速可靠地打包我的捆绑包并将其部署到容器中。直到今天我只是通过eclipse导出jar然后编辑清单来做这件事。

我认为最好的方法（不需要太多工作）是使用一个带有目标的大型 Ant 构建文件来解决我最迫切需要的事情（现在创建 OSGi 包），然后从 eclipse 中逐步移动更多构建逻辑进入构建文件（我知道有一种简单的方法可以通过 eclipse 运行 ant 目标，甚至用自定义构建文件替换 eclipse 的 autoprojectbuild 逻辑）。

所以这是我的计划：

1) 创建 1 个主构建文件，其中包含 src 目录中的所有内容（包含所有项目）

2) 使用 OSGi 包创建用于构建项目的任务。使用 manifest.txt 和我的包的手工清单并复制粘贴（通过 ant 任务）此包中需要的所有 jar，并使用 Bundle-ClassPath 声明我的内部包依赖项

3) 创建 JUnit 测试运行器作为自定义目标

4) 为构建各种项目创建其他目标

5) 最后在发布之前，创建大目标“dist”来打包整个软件

所以我的两个问题是：

我的这个计划好吗（就开发时间和合理的复杂性而言）？

使用 1 个大的构建文件有什么缺点吗？我阅读了 Ant in Action 书籍的一部分，但看起来多个构建文件只会导致更多复杂性（声明项目之间的依赖关系并不容易。OTH 有 1 个大文件，我可以使用目标依赖属性）。

Answer 1

进行脚本化构建/部署几乎总是一个好的步骤。它不仅为自动化部署提供了更多可能性，还为测试构建、持续集成等提供了自动化。就我个人而言，我不会太执着于尝试在 eclipse（您的 IDE）和构建工具之间进行集成。如果它可以轻松地在 eclipse 中单击某些东西，那很好，但它可能值得努力从命令行运行脚本变得舒适。如果您发现 ant 不是适合您的项目的工具，或者您可能希望有一天迁移到不同的 IDE，那么将这两个问题（开发经验，与构建生命周期）分开也会带来更多选择。

Answer 2

听起来是 Maven 而不是 Ant 的好候选。您所说的所有事情都包含在 Maven 原型中。这是一个陡峭的学习曲线，但确实值得努力。