在Hudson或其他CI工具中使用Ant自动检出和编译Eclipse项目的最佳方法？
我们有几个产品有很多共享代码，必须保留多个版本。
为了解决这个问题，我们使用了很多Eclipse项目，其中一些包含库jar，还有一些包含共享源代码（在几个项目中，为了避免获得具有大量依赖关系的巨大堆，同时能够从头开始编译所有内容以确保源和二进制文件是一致）。 我们使用projectSet.psf管理那些，因为这些可以直接从CVS中拉出所有项目并留下完全准备好的工作区。 我们不直接进行ant构建或使用maven。
我们现在希望能够将所有这些项目及其各种版本放在一个连续集成工具中 – 我喜欢Hudson但这只是一个品味问题 – 这实际上意味着我们需要一种自动方式来检查项目到一个新的工作区，并按照每个项目中的项目文件中的描述编译源文件夹。 Hudson没有提供这样的方法来构建项目，所以我一直在考虑采用这种方法的最佳方法。
想法已经存在
- 查找或编写一个了解projectSet.psf并映射到cvs-checkout和编译标签的ant插件/转换器。
- 从Eclipse中创建build.xml文件并使用它们。 我试过这个，发现结果很冗长，绝对位置不好用自动工具把文件放在他们想要的地方。
- 编写一个了解projectSet.psf的Hudson插件来派生配置并构建它。
- 只要咬紧牙关并在东西破裂时手动创建和更新CI配置 – 我不喜欢这个:)
我真的很想知道其他人的经历，所以我可以决定如何处理这个问题。
编辑：另一个选项可能是使用CI，它更了解Eclipse项目和/或项目集。 我们没有宗教信仰 – 这只是让自己无需自己动手就可以运行的问题。 巡航控制会是一个更好的选择吗？ 其他？
编辑：发现ant4eclipse有一个“团队项目集”工具。 http://ant4eclipse.sourceforge.net/
编辑：使用ant4eclipse和ant-contrib ant扩展来构建一个完整的工作区作为一个sjgned runnable jar文件，类似于Eclipse 3.5M6中的Runnable Jar工具。 我仍然依赖于Eclipse来创建初始的空工作空间，并提取ProjectSet，这是下一个障碍。
编辑：使用双配置结束，即Hudson从CVS中提取与ProjectSet.pdf文件中列出的相同的模块集（需要具有相同的标记），使它们彼此相邻。 然后ant4eclipse与嵌入在主模块中的projectSet.psf文件很好地配合。 警告：Hudson中的模块列表必须手动更新，之后需要手动工作区清理才能让Hudson“发现”现在有比以前更多的项目。 这对我们来说已经好几个月了，但是让一切都在ant文件中运行是相当繁琐的。
编辑：使用ant4eclipse的“使用团队项目”和项目面板中的Ctrl-A，Ctrl-C以及Hudson的CVS项目中的Ctrl-V已经certificate可以很好地满足我们的需求（对于成熟项目而言很少改变）。 我正在等待ant4eclipse 1.0的发布 – http://www.ant4eclipse.org/ ，目前在里程碑2中 – 看看有多少本土function可以被ant4eclipse的东西取代。
编辑：ant4eclipse是在M4的20100609，所以http://www.ant4eclipse.org/node?page=1的时间表有些滑落。
编辑：使用我们的ant4eclipse方法更长时间后的结论是构建脚本变得非常粗糙并且难以维护。 团队ProjectSet工具（ant4eclipse用于定位项目）也适用于基于CVS的存储库，但在我们迁移到git之后却没有（这本身就是一件大事）。 新项目很可能基于maven，因为这在Jenkins中得到了很好的支持。
编写一个了解projectSet.psf的Hudson插件来派生配置并构建它。
这似乎是我获胜的答案。
我使用CruiseControl而不是Hudson，但根据我的经验，如果你可以创建一个解决你的问题的插件，它将很快得到回报。 编写一个适合您的解决方案的插件通常非常容易，而不是需要在类似情况下为每个人工作的插件。
我不完全确定我理解这个问题，但听起来根本问题是你有很多项目，其中一些项目依赖于其他项目。 一些更接近依赖树“叶子”的项目需要能够使用更“核心”项目的“稳定”（或之前“发布”）版本。
我使用Hudson ， ant和ivy解决了这个问题。 我遵循Clark在实用项目自动化中展示的模式（他没有演示依赖性问题和解决方案，他使用CruiseControl而不是哈德森。）
我有一个手写的ant构建文件（我们称之为“cc-build.xml”，因为我们的CruiseControl根目录。）此文件负责从CM存储库刷新项目的工作空间并标记内容以供将来使用参考。 然后它将控制交给另一个由每个项目开发人员提供的手写ant构建文件（build.xml）。 该项目负责传统的构建步骤（编译，打包等）。需要将可安装的工件，unit testing报告等吐出到Hudson工件目录中。 根据我的经验，自动生成的构建文件（由Eclipse或其他类似的IDE）将永远不会接近于使其足够健壮以便在CI场景中使用。
此外，它使用常春藤来解决自己的依赖关系。 Ivy支持精确指定的依赖版本（例如“使用版本1.1”），它支持“模糊版本”（例如“使用版本1.1+”或“在集成状态下使用最新版本。”）我们的项目通常开始指定一个非常正在进行开发的内部项目的“模糊”版本，当它们接近发布点时，它们“冻结”依赖版本，以便东西停止在它们下面移动。
非叶子项目（其他项目的依赖项目）也使用常春藤将其工件发布到我们的内部常春藤存储库。 该存储库保留了所有过去的依赖项构建，因此任何项目都可以始终依赖于任何其他先前版本。
最后，Hudson中的每个项目都配置为具有构建触发器，当其任何依赖项目成功构建时，该触发器将导致重建。 这导致他们再次使用（可能）新的常春藤依赖版本构建。
值得注意的是，一旦启动并运行，自动化构建输入的一致自动“标记”或“标记”对您来说至关重要 – 否则对构建后问题进行故障排除将导致必须解决大黄蜂的巢找到原始来源。
为我们的环境获得所有这些设置需要花费相当多的精力（主要是设置常春藤存储库和ant构建文件），但是在手动管理依赖关系和减少故障排除工作的情况下，它已经多次为自己付出了代价。
我已经尝试过Cruise Control（CC）和Hudson用于我们的CI解决方案。 我们（作为一家公司）决定哈德森。 但是对于你的问题“CC是否支持Eclipse项目构建”，答案并不是我所知道的。 CC支持更多不同的构建工具和源代码控制系统，但配置和使用起来有点困难。 至于Hudson，配置和使用它更简单。 我们为CC和Hudson开发了我们的定制插件，用于我们构建周期的部分，它们没有按原样提供。 至于插件开发，如果你知道/使用Maven，Hudson也会更简单。 但是如果你对Maven不熟悉，首先你需要学习maven的基本用法来成功开发一个Hudson插件。 但是一旦你理解了maven的基本用法，插件开发，测试甚至调试在Hudson中都比较简单。
对于您的特定问题，我可以考虑使用Eclipse插件的解决方案。 您可以开发自己的Eclipse插件，例如从（可配置的）文件夹中获取psf文件，并使用Eclipse内部来处理这些psf。 我的意思是你可以使用现有的Eclipse源代码来获取psf文件，检查它的项目定义并编译这些项目。 您的这个Eclipse插件可能有一个首选项页面（您可以通过Eclipse访问 – > Window – > Preferences）并配置它将用于查找psf文件的文件夹。 您的Eclipse插件还应该有一种方法来启动psf处理而无需用户交互。 为此，您可以使用ipc来触发您的过程。 我的意思是你的Eclipse插件可以监听端口，你可以编写另一个java应用程序，它将通过这个端口连接到你的插件并触发它的进程。 对于CI部分，您可以使用CC或Hudson并使用其外部流程执行支持。 如果您使用的是Windows，则可以编写一个bat文件（对于Linux sh文件），该文件首先启动安装了插件的Eclipse。 然后它启动你的Java应用程序，它将与你的Eclipse插件进行通信，以触发你的进程。 从CI工具中，您需要运行bat / sh文件来触发您的过程。