OSGi 对模块化 Web 项目是否过度杀伤？答案

【问题标题】：Is OSGi overkill for modularized Web projects?OSGi 对模块化 Web 项目是否过度杀伤？
【发布时间】：2011-06-24 04:27:56
【问题描述】：

我主要使用 Java、Maven 和 Spring 开发一个大型 Web 项目。但是，针对特定客户需求创建了不同风格的 Web 项目。例如，如果一个客户想要一个 Twitter 页面，而另一个客户不想要，那么我需要能够在有或没有该 Twitter 页面的情况下构建该 Web 项目的风格。

我一直在研究 Maven 覆盖和 OSGi 作为两个选项。从基础覆盖层复制资源时，Maven 覆盖层往往需要很长时间才能构建。我将 Spring OSGi Web 视为一种选择，因为它们似乎正走在为 Web 项目模块化小块（控制器、视图、JS/资源/图像）的正确轨道上。

OSGi 是否矫枉过正？这是我需要使用的吗？有更好的吗？

【问题讨论】：

标签： java spring maven osgi modularity

【解决方案1】：

如果您需要在运行时添加/删除不可预见的功能（和代码）（而不仅仅是启用或禁用它），OSGI 非常棒，但大多数时候 Web 应用不需要这样做。

因此，在您的情况下，我建议尽可能使用配置（文件）来启用或禁用功能。这还有一个好处，就是您只需要一个 WAR。

处理“如何将配置文件放入WAR”的问题，有几种方法（Different files to be packaged in a Maven war project）：

use maven environements - （好吧，你有几个 WAR，但唯一不同的是配置文件，并且构建过程变得不那么慢，因为每个环境只完成 WAR 打包过程）
将配置存储在 WAR 之外
将配置存储在 WAR 之外，例如在数据库中

【讨论】：

我认为环境不是答案。我不是为许多具有不同配置的环境构建一个 WAR，而是为许多具有不同功能的不同 WAR。例如，index.jsp 和 login.jsp 可能会在所有项目之间共享，但 profile.jsp 仅适用于部分项目。
@Matt Fisher - 关于环境的提示仅在与配置文件结合使用时才有用。如果你真的有理由添加和删除源代码，那就使用 osgi。

【解决方案2】：

您可能对Spring Slices 感兴趣。它基本上允许您将 Web 应用程序的片段部署为单独的包。根据您的整体产品的复杂性，这可能是可取的。

我已经有一段时间没有认真看它了，所以我不太确定它的当前状态，尽管我希望它自从我上次看以来已经有了很大的改善。

任何有更多最新信息的人请随时添加链接。

http://blog.springsource.com/2009/08/07/slices-menu-bar-screencast/

【讨论】：

我也简要地看过这个。我认为 Spring Slices 是正确的方向，它允许开发人员选择哪些模块来构建项目/WAR。对此进行更多调查...
其实比这更令人印象深刻。您在单独的包中开发站点的功能，然后您可以在运行时部署/升级功能。考虑在购物车和商店部分继续运行时升级论坛部分。

【解决方案3】：

根据经验，Matt 尽量只拥有一个版本的应用程序，并尝试使用配置属性对其进行管理。想象一下，如果您有 10 个客户端，每个客户端都有几个功能，但没有两个客户端具有相同的功能集，会发生什么情况。

【讨论】：

有点意思...为什么我要在不需要它们的 WAR 中包含页面、控制器、图像、脚本等？我不认为模块化一个项目（一组项目）是坏事——我正在寻找最好的方法。

【解决方案4】：

https://github.com/griddynamics/banshun 是 Spring 的 osgi-less 模块化支持两种自定义概念。它可以通过称为构建时自定义的通配符来拾取和实例化模块（子上下文），这意味着 maven 配置文件在 WAR 中放置了必要的覆盖。一种相反的方式是运行时自定义，当必要的模块根据属性定义时。

【讨论】：