将OSGi捆绑包分组以形成一致的'；应用程序'；

“OSGi方式”是开发包含离散的、连贯的功能片段的独立捆绑包。有时这些捆绑包包含实用程序类，有时它们依赖于实用程序类并建立自己的OSGi服务

另一方面，用户不太可能接触捆绑包。他们更关心应用程序，一个执行任务或解决问题的软件。通常，应用程序将使用多个捆绑包（例如，通过导入包导入）来执行其任务

在OSGi世界中，将这种关系正式化的最佳方式是什么？一个简单的示例要求是向用户显示应用程序（而不是捆绑包）的当前版本号。如何发现此版本号

Eclipse有一个称为“特性”的概念，但这不是OSGi标准

彼得·克里恩斯（Peter Kriens）的文章很有意义。我从中得到的好处是，应用程序可以映射到捆绑包；只是捆绑包以某种方式使用了其他捆绑包。但是，如果要使用导入包创建应用程序包，我不认为从开发的角度来看这是可行的

一种方法可能是使用Require bundle并拥有自己的版本的“应用程序包”，但Require bundle在OSGi世界中并不受欢迎

---

然而，使用Import-Package来导入所有需要的包和所需的版本，会给开发人员增加一个很大的维护开销，我认为这是不可行的。每次进行最小的更改时，即使是对一个实现包，也必须更新包版本，然后在“应用程序包”中更新对包版本的依赖关系。

我想你要找的词是“子系统”，我想这里有一个OSGi草案规范

我个人的看法是：

构建您的捆绑包并将其存储在某个地方（例如，Sonatype Nexus服务器，我非常满意，它甚至支持OBR和生成p2数据的有限支持）

然后，“应用程序”是从该存储库中选择的具有特定版本的捆绑包，您可以对其重新进行版本设置

目前还没有真正的标准，我认为在这一点上，你需要选择一个非标准的。更改为标准一个或甚至支持多个一个的成本不应该太高

---

提及所有这些

如果您使用诸如OBR或新R5解析器之类的解析器，则使用导入包不一定会产生大量维护开销

---

但是，

Require Bundle

方式也是可能的。“应用程序”通常由少量（比如1-5个）“有趣”包组成。然后是所有其他的依赖项，如依赖项、SCR、Blueprint等。因此，您可以创建一个顶级应用程序包，使用

Require bundle

引用一小部分感兴趣的bundle，然后使用

Import Package

指定所有其他依赖项框架就是应用程序。。。imho在OSGi世界中最大的错误是将OSGi视为一个多租户框架，它不是为这个目的而设计的，也不是一个好的选择。在一个框架内，具有高度的内聚性，所有注册的服务都是您的服务。OSGi的体系结构模型允许您从通过服务连接的松散耦合组件编写应用程序。这是imho迄今为止在软件中获得的最好的组件（尽管不幸的是，将会有很多缺少的组件）

在bndtools中，我们不遗余力地帮助实现这个模型。bndtools bndrun文件基本上是一个可以部署的应用程序。bnd可以将这个bndrun文件转换成具有主类清单头的可运行Jar。（有了JPM，它将很容易部署到任何系统上。）

因此，工作流程基本上是：设计您的服务（=体系结构），查找标准组件，开发缺少的组件，测试组件，测试集成，并将整个过程变成一个可运行的JAR（或WAR）

---

显然，如果需要，您仍然可以在一个VM中运行多个框架，但千万不要在同一个框架中运行不同的无关应用程序，这不是一个好主意，生活已经够艰难了。

感谢您引入“子系统”。该幻灯片似乎涵盖了我的需求，例如子系统版本。有趣的是，“子系统内容”声明的是包（和其他东西），而不是包。不幸的是，我的OSGi IMPL的选择，菲利克斯，似乎没有一个子系统的概念。你可以考虑Apache Kalf，使用菲利克斯下（虽然我认为它也可以运行使用Enimox）。Karaf功能使用简单，据我所知，它几乎满足了您的需求。mvn:/style URL的使用也很巧妙。子系统是非常新的（规范上个月才定稿），因此您还没有找到任何稳定的实现。而且我觉得这太复杂了。。。你真的要将多个独立的应用程序部署到一个OSGi框架中吗？是的，有很多针对不同用例和粒度的规定。我真的只想把几个包分组。如果您使用ApacheKaraf，我还建议您现在就使用karaf特性。我们还致力于将子系统规范集成到Karaf中。因此，您可以稍后过渡到标准方式。那么您认为这是Require Bundle的合法使用吗？到目前为止，我的所有依赖项都使用导入包，因为我已经阅读并理解了什么是最佳实践。我认为Require Bundle的保留主要是对Eclipse的遗留支持。我确实认为这是

Require Bundle

的合法用例，是的。我相信Peter Kriens也同意。基本上，对于来自Java类的“真实”依赖项，必须始终使用

Im