我手头有一个相当大的（几个 MLOC）应用程序，我想将其拆分为更易于维护的单独部分。目前该产品由大约 40 个 Eclipse 项目组成，其中许多项目具有相互依赖性。仅此一点就使得连续构建系统变得不可行，因为每次签入都必须进行大量重建。
有没有一种“最佳实践”方法
- 识别可以立即分离的部分
- 直观地记录相互依赖关系
- 理清现有代码
- 处理我们需要应用于库的“补丁”（当前通过将它们放在实际库之前的类路径中来处理）
如果有（免费/开放）工具支持这一点，我将不胜感激。
尽管我没有任何使用 Maven 的经验，但它似乎强制采用了非常模块化的设计。我现在想知道这是否可以迭代地进行改造，或者使用它的项目是否必须从一开始就考虑到模块化的布局。
编辑2009-07-10
我们正在使用以下方法拆分一些核心模块：阿帕奇蚂蚁/常春藤 http://ant.apache.org/ivy。真正有用且设计良好的工具，不像 Maven 那样强加给你那么多。
我在我的博客上写下了一些关于我们为什么这样做的更一般的细节和个人观点 - 太长了，无法在这里发布，而且可能不是每个人都感兴趣，所以请自行决定遵循：www.danielschneller.com http://www.danielschneller.com/2009/07/modularizing-software-with-antivy-and.html
Using OSGi http://www.osgi.org/Main/HomePage可能很适合你。它将允许在应用程序之外创建模块。您还可以以更好的方式组织依赖关系。如果您正确定义了不同模块之间的接口，那么您可以使用持续集成，因为您只需重建在签入时受影响的模块。
OSGi 提供的机制将帮助您理清现有代码。由于类加载的工作方式，它还可以帮助您以更简单的方式处理补丁。
OSGi 的一些概念似乎很适合您，如维基百科所示： http://en.wikipedia.org/wiki/OSGi
该框架在概念上分为以下几个区域：
- 捆绑包 - 捆绑包是带有额外清单标头的普通 jar 组件。
- 服务 - 服务层通过为普通旧 Java 对象 (POJO) 提供发布-查找-绑定模型，以动态方式连接捆绑包。
- 服务注册中心 - 用于管理服务的 API（ServiceRegistration、ServiceTracker 和 ServiceReference）。
- 生命周期 - 用于生命周期管理（安装、启动、停止、更新和卸载捆绑包）的 API。
- 模块 - 定义封装和依赖关系声明的层（包如何导入和导出代码）。
- 安全性 - 通过将捆绑包功能限制为预定义功能来处理安全方面的层。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
