我在OSGi上看到了很多演讲，我认为这对于实施更好的模块化听起来很有希望。显然“hotdeployment”和“并行运行不同版本的x”也是市长卖点。
我想知道OSGi承诺解决的问题是否是一个问题......？这让我想起了早期的OO，当时类似的声称是女佣：
当OO 是新的时，最重要的论点是可重用性。人们普遍声称，当使用面向对象时，人们只需要“一次写入”，然后就可以“随处使用”。
在实践中，我只看到这适用于一些非常低级的例子。我认为这样做的原因是编写可重用的代码很难。从技术上讲，但从界面设计的角度来看。您必须预测未来的客户将如何使用您的课程并提前做出正确的选择。根据定义，这很困难，因此潜在的可重用性好处往往无法实现。
有了OSGi ，我怀疑在这里我们可能会再次陷入承诺，我们没有真正拥有的问题的潜在解决方案。或者如果我们拥有它们，我们没有足够大的数量和严重程度，以便购买OSGi以获得帮助。 “Hotdeployment”作为模块子集的例子绝对是一个好主意，但它真正的工作频率是多少？多久没有，因为事实证明你对特定问题的模块化是错误的？如何在多个模块之间共享模型实体？这些模块都必须同时更换吗？或者，您是否将对象展平为基元并仅使用模块间通信中的对象，以便能够保持接口契约？
应用OSGi时最困难的问题 ，我认为，可以使模块化“正确” 。类似于在OO中使用OSGi获取类的接口，问题保持不变，这次是更大规模，包甚至服务级别。
正如您可能已经猜到的那样，我目前正在尝试评估OSGi以用于项目。我们遇到的主要问题是随着代码库的增长而增加复杂性，并且我希望在具有越来越多定义的交互的较小模块中打破系统。
谢谢！
答案 0 :(得分：21)
OSGi得到了回报，因为它在运行时强制执行模块化，这是您以前没有的，通常会导致纸上设计和实现分离。这可能是开发过程中的一大胜利。
如果您让团队专注于单个模块（可能是一组捆绑），并且您的模块化正确，那么它确实有助于让团队更轻松地工作。有人可能会说，使用像Ant + Ivy或Maven和依赖项这样的构建工具可以做同样的事情，OSGi使用的依赖关系的粒度在我看来远远优于，不会导致典型的“拖入一切加上厨房水槽” JAR级别依赖性导致。
具有较少依赖性的模块化代码往往会导致更清晰，更少的代码，从而导致更少的错误，更容易测试和解决。它还促进设计组件尽可能简单明了，同时可以选择插入更复杂的实现，或者将缓存等方面添加为单独的组件。
热部署，即使您不在运行时使用它，也是一个非常好的测试，可以验证您是否正确地模块化了应用程序。如果您无法以随机顺序启动捆绑包，则应调查原因。此外，如果您可以更新任意捆绑包，它可以使您的开发周期更快。
只要您可以管理您的模块和依赖项，大型项目就可以管理并且可以轻松演变（从可以说是糟糕的“完全重写”中拯救您。）
OSGi的缺点？这是一个非常低级的框架，虽然它可以很好地解决问题，但仍有一些事情你需要自己解决。特别是如果您来自Java EE环境，在那里您可以获得免费的线程安全性以及其他一些在您需要时非常有用的概念，您需要自己在OSGi中提供这些解决方案。
常见的缺陷是不在OSGi之上使用抽象来使普通开发人员更容易。永远不要让他们手动弄乱ServiceListeners或ServiceTrackers。仔细考虑捆绑包是什么，不允许这样做：您是否愿意让开发人员访问BundleContext，或者使用某种形式的声明模型隐藏所有这些内容。
答案 1 :(得分：9)
我已经使用OSGi多年了（虽然在eclipse项目的上下文中，而不是在web项目中）。很明显，框架并没有让你思考如何模块化。但它使您能够定义规则。
如果您使用包并定义（在设计文档中？Verbal？）某些包可能无法访问其他包中的类，而没有强制执行此约束，它将被破坏。如果您雇用新的开发人员，他们不了解规则。他们会破坏规则。使用OSGi，您可以在代码中定义规则。对我们来说，这是一个巨大的胜利，因为它帮助我们维护了系统的架构。
OSGi不会降低复杂性。但它肯定有助于处理它。
答案 2 :(得分：5)
我现在使用OSGI超过8年了，每次我在非OSGI项目中潜水时，如果没有安全带，我会感觉超速。 OSGI使项目设置和部署更加困难，并迫使您提前考虑模块化，但是您可以轻松地在运行时强制执行规则。 以maven apache camel为例。当您创建一个新的maven项目并添加apache camel作为依赖项时，应用程序似乎具有所有依赖项，并且您只会在运行时注意到ClassNotFoundExceptions，这很糟糕。当您在OSGI容器中运行并加载apache camel模块时，未启动具有未满足依赖关系的模块，并且您事先知道问题所在。
我也一直使用热部署，并且无需重启即可快速更新应用程序的部分内容。
答案 3 :(得分：4)
我在一个项目中使用过OSGI（我承认 - 不是很多）。它提供了很好的承诺，但正如@Arne所说，你仍然需要自己思考如何模块化。
OSGI 确实帮助我们的项目，因为它使架构更稳定。打破模块化更加“困难”，因此我们就如何模块化做出的决定在更长的时间内保持有效。
换句话说 - 没有OSGI，并且在时间压力下交付，有时你或你的团队成员会做出妥协，快捷方式和其他黑客攻击，而且架构的原始意图就会丢失。
因此OSGI并没有降低复杂性本身，但它保护它不会随着时间的推移而不必要地增长。我想这是件好事:)）
我没有使用热部署功能，因此我无法对此发表评论。
为了回答你的最后一点，它确实达到了我的期望，但它需要一个学习曲线和一些适应性，而且收益只是为了长期。
（作为旁注，你的问题让我想起了一句“maven是构建系统的问题”的格言）
答案 4 :(得分：4)
OSGi不会得到回报。事实上，OSGi并不容易使用，并且在一天或一年结束时，取决于您将工作时间花费多长时间，它不会增加价值：
我添加了以下幻灯片，我将跟进示例代码，演示如何强制使用OSGi。 http://www.slideshare.net/ielian/tdd-on-osgi
答案 5 :(得分：-1)
不，OSGI会让你早早变灰。