17

我手头有一个相当大的（几个 MLOC）应用程序，我想将其拆分为更易于维护的独立部分。目前该产品由大约 40 个 Eclipse 项目组成，其中许多项目具有相互依赖关系。仅此一项就使连续构建系统不可行，因为每次签入都必须进行大量重建。

是否有“最佳实践”方式

  • 识别可以立即分离的部件
  • 直观地记录相互依赖关系
  • 解开现有代码
  • 处理我们需要应用于库的“补丁”（目前通过将它们放在实际库之前的类路径中来处理）

如果有（免费/开放）工具来支持这一点，我将不胜感激。

尽管我对 Maven 没有任何经验，但它似乎强制进行了非常模块化的设计。我现在想知道这是否是可以迭代改造的东西，或者如果要使用它的项目必须从一开始就考虑到模块化的布局。

编辑 2009-07-10

我们正在使用Apache Ant/Ivy拆分一些核心模块。真正有用且设计精良的工具，不会像 maven 那样对您造成太大影响。

我在我的博客上写了一些更一般的细节和个人意见，说明我们为什么要这样做 - 太长了，不能在这里发布，可能不是每个人都感兴趣，所以请自行决定：www.danielschneller.com

4

7 回答 7

9

使用OSGi可能非常适合您。它将允许从应用程序中创建模块。您还可以以更好的方式组织依赖项。如果您正确定义了不同模块之间的接口，那么您可以使用持续集成，因为您只需重建您在签入时影响的模块。

OSGi 提供的机制将帮助您解开现有代码。由于类加载的工作方式，它还可以帮助您以更简单的方式处理补丁。

OSGi 的一些概念似乎很适合您，如 wikipedia 所示：

该框架在概念上分为以下几个方面：

  • Bundles - Bundles 是带有额外清单标头的普通 jar 组件。
  • 服务 - 服务层通过为普通的旧 Java 对象 (POJO) 提供发布-查找-绑定模型以动态方式连接捆绑包。
  • Services Registry - 用于管理服务的 API（ServiceRegistration、ServiceTracker 和 ServiceReference）。
  • Life-Cycle - 用于生命周期管理（安装、启动、停止、更新和卸载捆绑包）的 API。
  • 模块 - 定义封装和依赖声明的层（包如何导入和导出代码）。
  • 安全性 - 通过将捆绑功能限制为预定义功能来处理安全方面的层。
于 2009-05-19T07:35:18.967 回答
6

第一：祝你好运和好咖啡。你两个都需要。

我曾经有一个类似的问题。具有可怕循环依赖关系的遗留代码，即使在来自不同包（如 org.example.pkg1.A）的类之间也依赖于 org.example.pk2.B ，反之亦然。

我从 maven2 和新的 eclipse 项目开始。首先，我尝试确定最常见的功能（日志记录层、常用接口、常用服务）并创建 maven 项目。每次我对某个部件感到满意时，我都会将该库部署到中央 nexus 存储库，以便它几乎可以立即用于其他项目。

所以我慢慢地通过层来工作。maven2 处理依赖项，m2eclipse 插件提供了一个有用的依赖项视图。顺便说一句 - 将 eclipse 项目转换为 maven 项目通常并不难。m2eclipse 可以为您完成，您只需创建一些新文件夹（如 src/main/java）并调整源文件夹的构建路径。只需一两分钟。但是，如果您的项目是 eclipse 插件或 rcp 应用程序，并且您希望 maven 不仅要管理工件，还要构建和部署应用程序，那么预计会遇到更多困难。

就观点而言，eclipse、maven 和 nexus（或任何其他 maven 存储库管理器）是一个很好的开始基础。你很幸运，如果你有一个很好的系统架构文档并且这个架构真的被实现了；）

于 2009-05-19T07:38:53.297 回答
3

我在一个小型代码库（40 kloc）中也有类似的经历。没有°规则”：

  • 使用和不使用“模块”编译以查看它的用法
  • 我从“叶子模块”开始，没有其他依赖的模块
  • 我处理了循环依赖（这是一个非常容易出错的任务）
  • 使用 maven，可以在 CI 流程中部署大量文档（报告）
  • 使用 maven，您始终可以在 netbeans 中查看站点中的内容（带有
    非常好的有向图）
  • 使用 maven，您可以在代码库中导入库代码，应用源代码补丁并与您的产品一起编译（有时这很容易，有时却很困难）

还要检查依赖分析器：（ 来源：javalobby.org）

网豆：


（来源：zimmer428.net）

于 2009-05-19T07:58:44.370 回答
1

对于现有系统迁移到 Maven 是很痛苦的。但是它可以轻松应对100多个模块项目。

于 2009-05-19T19:16:40.690 回答
1

您需要决定的第一件事是您将迁移到什么基础设施。它应该是许多独立维护的模块（转换为单独的 Eclipse 项目），还是您将其视为一个单独的代码块，它是作为一个整体进行版本控制和部署的。第一个非常适合迁移到类似 Maven 的构建环境 - 后者用于同时包含所有源代码。

在任何情况下，您都需要运行持续集成系统。您的首要任务是自动构建代码库，这样您就可以让 CI 系统监视您的源存储库并在您更改内容时重新构建它。我决定在这里使用非 Maven 方法，我们专注于拥有一个简单的 Eclipse 环境，因此我使用 ant4eclipse 和 Team ProjectSet 文件（我们无论如何都使用）创建了一个构建环境。

下一步将摆脱循环依赖——这将使您的构建更简单，摆脱 Eclipse 警告，并最终让您进入“签出、编译一次、运行”阶段。这可能需要一段时间 :-( 当您迁移方法和类时，不要移动它们，而是提取或委托它们并留下它们的旧名称并将它们标记为已弃用。这会将您的解开与重构分开，并允许代码“外部”您的项目仍然可以使用您的项目中的代码。

您将从允许移动文件和保留历史记录的源存储库中受益。CVS 在这方面非常薄弱。

于 2009-05-19T22:21:58.087 回答
0

我不会推荐 Maven 作为遗留源代码库。只是试图调整一切以适应它，它可能会给你带来很多麻烦。

我想您需要做的是对您的项目进行架构布局。一个工具可能会有所帮助，但最重要的部分是组织模块的逻辑视图。

于 2009-05-19T07:35:15.893 回答
0

它不是免费的，但Structure101会为您提供尽可能好的工具支持，以达到您的所有要点。但为了记录，我有偏见，所以你可能也想看看 SonarJ 和 Lattix。;-)

于 2009-07-22T16:34:04.273 回答