我们有几种产品，它们有很多共享代码，并且必须维护多个版本。
为了处理这个问题，我们使用了很多 Eclipse 项目，有些包含库 jar，有些包含共享源代码（在几个项目中，以避免获得具有大量依赖项的巨大堆，同时能够从头开始编译所有内容，以确保源代码和二进制文件是持续的）。 我们使用projectSet.psf 来管理这些项目，因为它们可以直接从CVS 中拉出所有项目并留下一个完全准备好的工作区。 我们不直接进行 ant 构建或使用 maven。
我们现在希望能够将所有这些项目及其各种版本放入持续集成工具中 - 我喜欢 Hudson，但这只是一个品味问题 - 这本质上意味着我们需要一种自动方式来检查项目一个新的工作区，并按照每个项目中的项目文件中的描述编译源文件夹。 Hudson 没有提供这样的方法来构建项目，所以我一直在考虑解决这个问题的最佳方法是什么。
想法是
- 找到或编写一个 ant 插件/转换器，它可以理解 projectSet.psf 并映射到 cvs-checkout 和编译标签。
- 从 Eclipse 中创建 build.xml 文件并使用它们。 我尝试了这个，发现结果很冗长并且具有绝对位置，这对于将文件放置在想要的位置的自动工具来说并不好。
- 编写一个 Hudson 插件，它可以理解 projectSet.psf 来派生配置并构建它。
- 每当出现问题时，只要硬着头皮手动创建和更新 CI 配置 - 我不喜欢这样:)
我真的很想听听其他人的经验，这样我就可以决定如何解决这个问题。
编辑：另一个选择可能是使用更了解 Eclipse 项目和/或项目集的 CI。 我们没有宗教信仰——这只是让东西运行起来的问题，而不必自己做所有的事情。 巡航控制也许是更好的选择？ 其他的？
编辑：发现 ant4eclipse 有一个“团队项目集”设施。 http://ant4eclipse.sourceforge.net/
编辑：使用 ant4eclipse 和 ant-contrib ant 扩展来构建一个完整的工作区，作为一个可运行的 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 已经证明工作得足够好，足以让我们接受（对于成熟的项目，这很少改变）。 我正在等待 ant4eclipse 1.0 的发布 - http://www.ant4eclipse.org/，目前处于里程碑阶段2 - 看看有多少自制功能可以用 ant4eclipse 的东西替代。
编辑： ant4eclipse 截至 M4 中的 20100609，因此时间表位于 http://www.ant4eclipse.org /node?page=1 有所下滑。
编辑：长期使用 ant4eclipse 方法后我的结论是构建脚本变得非常粗糙并且难以维护。 另外，Team ProjectSet 工具（ant4eclipse 使用它来定位项目）对于基于 CVS 的存储库非常有效，但在我们迁移到 git 后就不行了（这本身就是一件大事）。 新项目很可能基于 Maven，因为 Jenkins 对此有很好的支持。
We have several products which have a lot of shared code and which must be maintained several versions back.
To handle this we use a lot of Eclipse projects, some contain library jars, and some contain shared source code (in several projects to avoid getting a giant heap with numerous dependencies while being able to compile everything from scratch to ensure that source and binaries are consistent). We manage those with projectSet.psf's as these can directly pull all projects out from CVS and leave a fully prepared workspace. We do not do ant builds directly or use maven.
We now want to be able to put all these projects and their various versions in a Continous Integration tool - I like Hudson but this is just a matter of taste - which essentially means that we need to get an automatic way to check out the projects to a fresh workspace, and compile the source folders as described in the project-files in each project. Hudson does not provide such an approach to build a project, so I have been considering what the best way to approach this would be.
Ideas have been
- Find or write an ant plugin/converter that understands projectSet.psf's and map to cvs-checkout and compile tags.
- Create the build.xml files from within Eclipse and use those. I tried this, and found the result to be verbose and with absolute locations which is not good with automatic tools putting files where they want to.
- Write a Hudson plugin which understands projectSet.psf's to derive a configuration and build it.
- Just bite the bullet and manually create and update the CI configuration whenever stuff breaks - I don't like this :)
I'd really like to hear about other peoples experiences so I can decide how to approach this.
Edit: Another option might be using a CI which knows better about Eclipse projects and/or project sets. We are not religious - this is just a matter of getting stuff running without having to do everything ourselves. Would Cruise Control be a better option perhaps? Others?
Edit: Found that ant4eclipse has a "Team Project Set" facility. http://ant4eclipse.sourceforge.net/
Edit: Used the ant4eclipse and ant-contrib ant extensions to build a complete workspace as a sjgned runnable jar file similar to the Runnable Jar facility in Eclipse 3.5M6. I am still depending on Eclipse to create the initial empty workspace, and extract the ProjectSet, so that is the next hurdle.
Edit: Ended up with a dual configuration, namely that Hudson extracts the same set of modules as listed in the ProjectSet.pdf file from CVS (which needs to have the same tag) causing them to be located next to each other. Then ant4eclipse works well with the projectSet.psf file embedded in the main module. Caveat: Module list in Hudson must be manually updated, and it appears that a manual workspace cleanup is needed afterwards to let Hudson "discover" that there is more projects now than earlier. This has now worked well for us for a couple of months, but it was quite tedious to get everything working inside the ant file.
Edit: The "Use Team Projects" with ant4eclipse and a Ctrl-A, Ctrl-C in Project Panel with a Ctrl-V in the CVS projects in Hudson has turned out to work well enough for us to live with (for mature projects this is very rarely changed). I am awaiting the release of ant4eclipse 1.0 - http://www.ant4eclipse.org/, currently in milestone 2 - to see how much homegrown functionality can be replaced with ant4eclipse things.
Edit: ant4eclipse is as of 20100609 in M4 so the schedule at http://www.ant4eclipse.org/node?page=1 is slipping somewhat.
Edit: My conclusion after using our ant4eclipse approach for a longer period is that the build script get very gnarly and is hard to maintain. Also the Team ProjectSet facility (which ant4eclipse use to locate the projects) which works well for CVS based repositories, but not after we migrated to git (which is a big thing in itself). New projects will most likely be based on maven, as this has good support in Jenkins.
发布评论
评论（3）
我不完全确定我理解这个问题，但听起来根本问题是你有很多项目，其中一些项目依赖于其他项目。 一些更接近依赖树“叶子”的项目需要能够使用更“核心”项目的“稳定”（或之前“发布”）版本。
我使用 Hudson、ant 和 ivy。 我遵循 Clark 在 实用项目自动化 中演示的模式（他不演示依赖性问题和解决方案，并且他使用 CruiseControl 而不是 hudson。）
我有一个手写的 ant 构建文件（我们称其为“cc-build.xml”，因为我们的 CruiseControl 根源。）该文件负责刷新CM 存储库中项目的工作空间，并标记内容以供将来参考。 然后，它将控制权交给每个项目开发人员提供的另一个手写的 ant 构建文件 (build.xml)。 该项目负责传统的构建步骤（编译、打包等），需要将可安装的工件、单元测试报告等吐出到 Hudson 工件目录。 根据我的经验，自动生成的构建文件（由 Eclipse 或其他类似的 IDE）永远无法达到足以在 CI 场景中使用的稳健性。
此外，它还使用 ivy 来解决其自身的依赖关系。 Ivy 支持精确指定的依赖版本（例如“使用版本 1.1”），并且支持“模糊版本”（例如“使用版本 1.1+”或“在集成状态下使用最新版本。”）我们的项目通常一开始就指定一个非常正在进行开发的内部项目的“模糊”版本，当它们接近发布点时，它们“冻结”依赖版本，以便东西停止在它们下面移动。
非叶项目（依赖于其他项目的项目）也使用 ivy 将其工件发布到我们的内部 ivy 存储库。 该存储库保留依赖项的所有过去版本，以便任何项目始终可以依赖于任何其他以前的版本。
最后，Hudson 中的每个项目都配置为具有一个构建触发器，当其任何依赖项目成功构建时，该触发器会导致重建。 这会导致它们使用（可能）新的 ivy 依赖版本再次构建。
值得注意的是，一旦你启动并运行它，自动化构建输入的一致的自动化“标签”或“标记”对你来说至关重要 - 否则解决构建后问题将导致必须解决一个问题。寻找马蜂窝的原始出处。
为我们的环境完成所有这些设置需要花费相当多的精力（主要是设置 ivy 存储库和 ant 构建文件），但它在节省手动管理依赖项的麻烦和减少故障排除工作方面已经物有所值。
I'm not completely sure I understand the problem, but it sounds like the root issue is that you have many projects, some of which are dependent on others. Some of the projects that are closer to the "leaf" of the dependency tree need to be able to use "stable" (or previously "released") versions of the more "core" projects.
I solve exactly this problem using Hudson, ant, and ivy. I follow a pattern demonstrated by Clark in Pragmatic Project Automation (he doesn't demonstrate the dependency problems and solutions, and he uses CruiseControl rather than hudson.)
I have a hand-written ant build file (we call it "cc-build.xml", because of our CruiseControl roots.) This file is responsible for refreshing the working space for the project from the CM repository and labeling the contents for future reference. It then hands off control to another hand-written ant build file (build.xml) that is provided by each project's developers. This project is responsible for the traditional build steps (compile, packaging, etc.) It is required to spit out the installable artifacts, unit test reports, etc, to the Hudson artifacts directory. It is my experience that automatically generated build files (by Eclipse or other similar IDE's) will never get close to getting this sufficiently robust for use in a CI scenario.
Additionally, it uses ivy to resolve its own dependencies. Ivy supports precisely-specified dependency versions (e.g. "use version 1.1") and it supports "fuzzy versions" (e.g. "use version 1.1+" or "use the latest version in integration status.") Our projects typically start out specifying a very "fuzzy" version for internal projects under ongoing development, and as they get close to a release point, they "freeze" the dependency version so that stuff stops moving underneath them.
The non-leaf projects (projects that are dependents for other projects) also use ivy to publish their artifacts to our internal ivy repository. That repository keeps all past builds of the dependents, so that any project can always depend on any other previous version.
Lastly, each project in Hudson is configured to have a build trigger that causes a rebuild when any of its dependent projects successfully build. This causes them to get built again with the (possibly) new ivy dependent version.
It is worth noting that once you get this up and running, consistent automated "labeling" or "tagging" of an automated build's inputs is going to be critical for you - otherwise troubleshooting post-build problems is going to result in having to untangle a hornet's nest to find the original source.
Getting all of this setup for our environment took quite a bit of effort (primarily in setting up the ivy repository and ant build files,) but it has paid for itself many times over in saved headaches in manually managing the dependencies and decreased troubleshooting effort.
这对我来说似乎是获胜的答案。
我使用 CruiseControl 而不是 Hudson，但根据我的经验，如果您可以创建一个插件来解决您的问题，它将很快得到回报。 通常，编写一个适合您的解决方案的自定义插件非常容易，而不是需要为处于类似情况的每个人工作的插件。
That seems like the winning answer to me.
I work with CruiseControl rather than Hudson but in my experience if you can create a plugin that solves your problem it will quickly payoff. And it is generally pretty easy to write a plugin that is custom fit for your solution as opposed to one that needs to work for everyone in a similar situation.
我已经尝试了 Cruise Control (CC) 和 Hudson 作为我们的 CI 解决方案。 我们（作为一家公司）决定选择 Hudson。 但对于你的问题“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 sh 文件），该文件首先启动安装了您的插件的 Eclipse。 然后它启动您的 java 应用程序，该应用程序将与您的 Eclipse 插件通信以触发您的进程。 您需要从 CI 工具运行 bat / sh 文件来触发您的进程。
I have tried both Cruise Control (CC) and Hudson for our CI solution. We (as a company) decided on Hudson. But for your question "Does CC support Eclipse project build" the answer is no as far as I know. CC supports many more different build tools and Source Control systems but it is a bit more difficult to configure and use. As for Hudson, it is more simple to configure and use it. We developed our custom plugins for both CC and Hudson for the parts of our build cycle that they do not provide as is. As for plugin development, if you know / use Maven, Hudson is simpler too. But if you are not familiar to Maven, first you need to learn the basic usage of maven to successfully develop a Hudson plugin. But once you understand the basic usage of maven, plugin development, test and even debug is simpler in Hudson.
For your specific problem, I can think of a solution that makes use of Eclipse plugins as well. You can develop your own Eclipse plugin that for instance gets the psf files from a (configurable) folder, and use Eclipse internals to process these psf's. I mean you can use existing Eclipse source codes that takes a psf file, check-outs it's project definitions and compile these projects. This Eclipse plugin of yours may have a preference page (which you can access by Eclipse -> Window -> Preferences) and configure which folder it will use to look for psf files. Your Eclipse plugin should also have a way to start psf processing without user interaction. For this, you can use ipc to trigger your process. I mean your Eclipse plugin can listen for a port, and you can write another java application that will connect to your plugin through this port and trigger its process. As for CI part, you can use either CC or Hudson and use their external process execution support. If you are using Windows, you can write a bat file (for Linux sh file) that first launchs Eclipse that has your plugin installed. Then it launches your java application that will communicate with your Eclipse plugin to trigger your process. From your CI tool you will need to run your bat / sh file to trigger your process.