使用Hudson或其他CI工具中的Ant自动签出和编译Eclipse项目的最佳方法？

Question

我们有几种产品，它们有大量的共享代码，并且必须维护多个版本。

为了处理这个问题，我们使用了很多Eclipse项目，有些项目包含库jars，还有一些项目包含共享源代码(在几个项目中，为了避免获得具有大量依赖项的巨大堆，同时能够从头编译所有东西，以确保源代码和二进制文件是一致的)。我们管理那些使用ProjectSet.psf的项目，因为这些项目可以直接从CVS中提取所有项目，并留下一个完全准备好的工作区。我们不直接进行蚂蚁构建，也不使用maven。

我们现在希望能够将所有这些项目及其不同版本放在一个连续集成工具中--我喜欢Hudson，但这只是一个品味问题--这实际上意味着我们需要一种自动的方式将项目签出到一个新的工作区，并编译项目中描述的源文件夹--每个项目中的文件。Hudson没有提供这样一种方法来构建一个项目，所以我一直在考虑如何最好地解决这个问题。

一直以来

• 找到或编写一个蚂蚁插件/转换器，它可以理解projectSet.psf并映射到cvs-签出和编译标记。
• 在Eclipse中创建build.xml文件并使用这些文件。我尝试了这一点，并发现结果是冗长的和绝对的位置，这是不好的自动工具把文件放在他们想要的地方。
• 编写一个Hudson插件，它可以理解projectSet.psf来派生并构建配置。
• 只要咬紧牙关，随时手动创建和更新CI配置--我不喜欢这样:)

我真的很想听听别人的经历，这样我就可以决定如何处理这个问题了。

编辑:另一个选项可能是使用一个CI，它更了解Eclipse项目和/或项目集。我们没有宗教信仰--这只是一个不需要自己做的事情就能运转的问题。巡航控制会是一个更好的选择吗？其他?

编辑:发现ant4eclipse有一个"Team“工具。http://ant4eclipse.sourceforge.net/

编辑:使用ant4eclipse和ant4eclipse扩展构建一个完整的工作区，作为一个可运行的jar文件，类似于Eclipse3.5M6中的runnable工具。我仍然依赖于Eclipse来创建初始的空工作区，并提取ProjectSet，因此这是下一个障碍。

编辑:最终得到了双重配置，即Hudson从ProjectSet.pdf文件中提取相同的模块集(需要具有相同的标记)，从而使它们位于彼此的旁边。然后，ant4eclipse与嵌入在主模块中的projectSet.psf文件很好地工作。注意: Hudson中的模块列表必须手动更新，之后需要手动清理工作区，让Hudson“发现”现在比以前有更多的项目。这对我们已经有几个月的时间了，但是要在ant文件中完成所有的工作都是非常乏味的。

编辑: ant4eclipse的"Use Team Projects“和项目面板中的Ctrl、Ctrl和Hudson的CVS项目中的Ctrl已经证明对我们来说工作得很好(对于成熟的项目，这是很少改变的)。我正在等待ant4eclipse 1.0的发布--目前处于里程碑2中的http://www.ant4eclipse.org/ --来看看有多少国产功能可以被ant4eclipse东西所取代。

编辑: ant4eclipse在M4中是20100609岁，所以http://www.ant4eclipse.org/node?page=1的日程有所下滑。

编辑:我在使用了较长时间的ant4eclipse方法后得出的结论是，构建脚本变得非常粗糙，很难维护。此外，Team ProjectSet工具( ant4eclipse使用它来定位项目)对基于CVS的存储库很好地工作，但在我们迁移到git之后就不行了(这本身就是一件大事)。新的项目很可能是基于maven的，因为在Jenkins中有很好的支持。

Answer 1

编写一个Hudson插件，它可以理解projectSet.psf来派生并构建配置。

对我来说，这似乎是个成功的答案。

我使用的是CruiseControl而不是Hudson，但根据我的经验，如果您能够创建一个解决问题的插件，它将很快得到回报。而且通常很容易编写一个适合您的解决方案的插件，而不是需要在类似情况下为每个人工作的插件。

Answer 2

我不能完全确定我是否理解这个问题，但听起来根本问题是你有很多项目，其中一些项目依赖于其他项目。一些更接近依赖树的“叶子”的项目需要能够使用更“核心”项目的“稳定”(或先前“发布”)版本。

我使用哈德森、蚂蚁和常春藤精确地解决了这个问题。我遵循克拉克在实用工程自动化中演示的模式(他没有演示依赖问题和解决方案，他使用的是CruiseControl而不是hudson)。

我有一个手写的ant构建文件(我们称之为"cc-build.xml"，因为我们的CruiseControl根)。该文件负责从CM存储库中刷新项目的工作空间，并标记内容以供将来参考。然后，它将控制权交给另一个手写的ant构建文件(build.xml)，该文件由每个项目的开发人员提供。这个项目负责传统的构建步骤(编译、打包等)。它需要将可安装的工件、单元测试报告等吐出到Hudson工件目录。根据我的经验，自动生成构建文件(由Eclipse或其他类似IDE生成)将永远无法获得足够健壮的构建文件，以便在CI场景中使用。

此外，它还使用常春藤来解决自己的依赖关系。常春藤支持精确指定的依赖版本(例如“使用1.1版本”)，并且支持“模糊版本”(例如“使用版本1.1+”或“在集成状态下使用最新版本”)。我们的项目通常一开始就为正在开发的内部项目指定一个非常“模糊”的版本，当它们接近发布点时，它们会“冻结”依赖版本，从而停止在它们下面移动。

非叶项目(其他项目依赖的项目)也使用常春藤将它们的工件发布到我们的内部常春藤存储库。该存储库保存依赖方的所有过去的构建，这样任何项目都可以依赖于任何其他以前的版本。

最后，Hudson中的每个项目都被配置为具有一个生成触发器，当任何依赖的项目成功构建时，该触发器都会导致重建。这导致他们重新构建(可能)新的常春藤依赖的版本。

值得注意的是，一旦您启动并运行，自动生成输入的一致的自动“标记”或“标记”对您至关重要--否则，解决构建后的问题将不得不解开马蜂窝以找到原始源。

在我们的环境中获得所有这些设置需要付出相当大的努力(主要是在设置常春藤存储库和ant构建文件方面)，但在手动管理依赖项和减少故障排除工作量方面，它已经为自己付出了多次代价。

Answer 3

我已经尝试了克鲁斯控制(CC)和哈德森作为我们的CI解决方案。我们(作为一家公司)决定选择哈德逊。但对于“CC支持Eclipse项目构建”的问题，据我所知，答案是否定的。CC支持更多不同的构建工具和源代码管理系统，但是配置和使用起来有点困难。至于Hudson，配置和使用它更简单。我们为CC和Hudson开发了自定义插件，用于我们构建周期中不提供的部分。至于插件开发，如果您知道/使用Maven，Hudson也更简单。但是，如果您不熟悉Maven，那么首先需要了解maven的基本用法，才能成功地开发Hudson插件。但是，一旦您了解了maven的基本用法，插件开发、测试甚至调试在Hudson中就更简单了。

对于您的具体问题，我也可以想到一个使用Eclipse插件的解决方案。您可以开发自己的Eclipse插件，例如从一个(可配置的)文件夹获取psf文件，并使用Eclipse内部处理这些psf，我的意思是您可以使用现有的Eclipse源代码来获取psf文件，签出它的项目定义并编译这些项目。您的这个Eclipse插件可能有一个首选项页面(您可以通过Eclipse -> ->首选项访问该页面)，并配置它将使用哪个文件夹查找psf文件。您的Eclipse插件还应该有一种方法来启动psf处理，而不需要用户交互。为此，可以使用ipc触发进程。我的意思是您的Eclipse插件可以侦听端口，您可以编写另一个java应用程序，通过这个端口连接到插件并触发它的进程。至于CI部件，您可以使用CC或Hudson，并使用它们的外部流程执行支持。如果您正在使用Windows，您可以编写一个bat文件(用于Linux文件)，该文件首先启动安装了插件的Eclipse。然后启动您的java应用程序，该应用程序将与您的Eclipse插件通信，以触发您的进程。从您的CI工具，您将需要运行您的bat / sh文件来触发您的进程。