eclipse - 将 Eclipse 与大型工作区结合使用

Question

我们当前的产品基于 Eclipse RCP。当我们尝试将整个代码库放在一个 Eclipse 工作区中并且我们想知道其他人在做什么时，我们开始遇到问题。

这是我们的设置:

1. ~225 个 eclipse 项目(全部在 trunk/project 中)
2. ~30 个 Eclipse 功能(全部在 trunk/features 中)
3. 约 90 万行代码

我们发现了一些不同的瓶颈:

1. Windows 上的 SVN 非常慢(尝试过 TortoiseSVN、SmartSVN、命令行 svn)，更新可能需要 5-8 分钟以上，而且只更新 10 个小文件。唯一合理的客户端是 subclipse/subversive，但是它们还有其他问题，我们在处理它们时遇到了一些麻烦。
2. Eclipse 刷新可能需要 3-5 分钟
3. Eclipse 构建可能需要 5-15 分钟

我认为该解决方案限制了任何一个开发人员在任何给定时间需要 checkout 和事件的项目数量，我只是想看看其他人是否有任何有效的良好实践/政策对于他们来说。

例如，我的第一个想法是将目标平台设置为主干中的最后一个“安全”构建，然后仅 checkout 其上的项目。这有效，但不会告诉您是否破坏了任何依赖于您已有效覆盖的项目的项目。

另一个想法是使用项目集并以这种方式检查您需要什么。

还有其他人遇到过这个问题吗？如果是这样，您会采取什么措施来解决这个问题？

谢谢。

Answer 1

我们针对这种配置采用的策略是以部署概念为中心的。

任何项目都负责构建要交付的文件集(jar、war、ear...)，然后对其进行版本控制。

这意味着:

• 任何负责测试整个系统的“集成团队”都可以通过向 VCS 发出一个请求来快速更新所有交付内容，而无需全部重建。因此就有了“部署”这个词:这种方法促进了它的发展。

• 对于您的问题，更重要的是，任何项目只需要查询它需要编译的交付即可工作并进行代码演变。

因此，对于任何给定的项目，实际上只有一个在 Eclipse 中打开，并且它引用来自其他项目的各种库。

这也迫使我们:

• 重新思考所有项目之间的各种依赖关系(检测要删除的某些循环依赖关系的情况)，
• 当我们意识到多个项目过于“细粒度”并且需要聚合在一起时，重新检查了我们的应用架构。

<小时/>

基本上有两种方法:

• 基于系统，所有应用程序的每个部分都可以一起开发，并且您需要的每个项目都具有源依赖性
• 基于组件，您的项目没有源依赖项，仅依赖于库。

在 eclipse-plugin 方法中，需要找到一个中间立场:
来自同一域的所有项目(例如“com.mycorp.fileutil[.XXX]”)都可以由 Eclipse 项目表示，并且它们之间具有源依赖关系。但是“com.mycorp.fileutil”所需的不属于该域的任何其他组件都应作为库导入，而不是作为源依赖项导入。因此我们提出了“以部署为中心，发布为先”的观点。