“OSGi 方式”是开发包含离散的、连贯的功能块的单独的包。有时这些包包含实用程序类，有时它们依赖于实用程序类并设置自己的 OSGi 服务。
另一方面，用户不太可能接触到捆绑包。他们更关心的是应用，一个执行任务或解决问题的软件。通常，应用程序将使用多个包（例如，通过 Import-Package 导入）来执行其任务。
在 OSGi 世界中正式化这种关系的最佳方式是什么？一个示例要求就像显示当前版本号一样简单申请的（不是捆绑包）给用户。如何发现这个版本号？
Eclipse 有一个称为“特性”的概念，但这不是 OSGi 标准。
彼得·克林斯有关于 OSGi 应用程序的文章 http://blog.osgi.org/2008/07/osgi-application-grouping.html他的文章很有道理。我的收获是应用程序可以映射到捆绑包；只是该捆绑包以某种方式使用了其他捆绑包。但是，如果要使用 Import-Package 创建应用程序包，从开发的角度来看，我不知道这如何可行。
一种方法可能是拥有一个使用 Require-Bundle 并拥有自己版本的“应用程序包”，但 Require-Bundle 在 OSGi 世界中是不受欢迎的。
但是，使用 Import-Package 导入具有所需版本的所有必需包，会添加一个重要的开发人员的维护开销达到了我认为不可行的程度。每次进行最小的更改时，即使是实现包，也必须更新包版本，然后在“应用程序包”中更新对包版本的依赖关系。
框架就是应用程序……恕我直言，OSGi 世界中最大的错误是将 OSGi 视为多租户框架，它不是为此目的而设计的，而且不太适合。在一个框架内部，内聚力很高，所有注册的服务都是your服务。 OSGi 的架构模型允许您从通过服务连接的松散耦合组件编写应用程序。恕我直言，这是迄今为止最好的软件（尽管不幸的是，有很多缺少的组件，但将会出现）。
在 bndtools 中，我们竭尽全力帮助建立这个模型。 bndtools bndrun 文件基本上是一个可以部署的应用程序。 bnd 可以将此 bndrun 文件转换为带有 Main-Class 清单标头的可运行 Jar。 （通过 JPM，可以轻松地在任何系统上部署。）
所以工作流程基本上是：设计服务（==架构），找到标准组件，开发缺失的组件，测试组件，测试集成，然后将整个事情变成可运行的 JAR（或 WAR）。
显然，如果需要的话，您仍然可以在单个虚拟机中运行多个框架，但永远不要在同一个框架中运行不同的不相关的应用程序，这不是一个好主意，生活已经够艰难的了。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
