【问题标题】:Using Eclipse with large workspaces将 Eclipse 与大型工作区一起使用
【发布时间】:2010-10-26 15:37:42
【问题描述】:

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

这是我们的设置:

  1. ~225个eclipse项目(全部在trunk/project中)
  2. ~30 个 Eclipse 功能(全部在主干/功能中)
  3. ~900k 行代码

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

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

我认为该解决方案限制了任何开发人员在任何给定时间都需要签出并处于活动状态的项目数量,我只是想看看其他人是否有任何有效的良好做法/政策给他们。

例如,我的第一个想法是将目标平台设置为来自主干的最后一个“安全”构建,然后在此之上检查项目。这有效,但不会告诉您是否破坏了任何依赖于您有效覆盖的项目的项目。

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

还有其他人遇到过这个问题吗?如果是这样,您正在采取什么措施来解决它?

谢谢。

【问题讨论】:

  • 255 个项目!哇 !好吧,我可以看到你所做的事情正在发生......
  • 是的,给一个开发团队几年时间,你会得到很多项目。此外,我们的应用程序使用 UI 运行,因此任何需要在无头模式下运行的项目/插件都不需要 UI 依赖项。我们遵循了 Eclipse 模型,其中插件功能被拆分。有核心插件和ui插件,如果有UI代码的话。例如:com.mycorp.fileutil(核心文件实用程序)com.mycorp.fileutil.ui(文件实用程序的 UI,例如文件对话框。)
  • 刚刚完成我的回答,表明需要中间立场(不是完整的源依赖,但也不是完整的库引用)

标签: eclipse eclipse-rcp


【解决方案1】:

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

任何项目都负责构建并版本化其要交付的文件集(jar、war、ear、...)。

这意味着:

  • 任何负责测试所有系统的“集成团队”都可以在向 VCS 的一个请求中快速更新所有交付,而无需全部重建。因此有了“部署”这个词:这种方法有助于实现。

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

所以对于任何给定的项目,在eclipse中实际上只打开了一个,它指的是来自其他项目的各种库。

这也迫使我们:

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

基本上有两种方法:

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

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

【讨论】:

  • “实际上只打开了一个” - 这听起来有点过于极端,依赖二进制文件而不是项目意味着您在 Eclipse 中几乎放弃了所有重构和搜索。我同意尽量减少 deps,但删除循环 deps 并外部化并制作 API:s 就足够了,然后您可以保留源 deps。
  • 我认为这是我们前进的道路。虽然有人签出的项目可能不止一个,但少于 10-20 个。 disown - 我实际上认为无法轻松重构/更改 API 是一个积极的结果。随着代码库的成熟,您希望人们在对“平台”进行更改之前必须进行思考。
  • @disown:是的。我已经完成了提出中间立场的答案。但我的观点仍然存在:255 个项目对于仅使用源依赖项进行管理来说太多了。
猜你喜欢
  • 2018-12-10
  • 1970-01-01
  • 1970-01-01
  • 2013-07-30
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-01-25
相关资源
最近更新 更多