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