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