“OSGi方式”是开发包含离散，连贯功能的单独包。有时这些bundle包含实用程序类，有时它们依赖于实用程序类并设置自己的OSGi服务。
另一方面，用户不太可能接触捆绑包。他们更关心应用程序，这是一个执行任务或解决问题的软件。通常，应用程序将使用多个包（例如，通过Import-Package导入）来执行其任务。
在OSGi世界中形式化这种关系的最佳方法是什么？一个示例要求就像显示应用程序的当前版本号一样简单捆绑包给用户。如何发现这个版本号？
Eclipse有一个名为'features'的概念，但这不是OSGi标准。
Peter Kriens written about OSGi applications并且他的文章很有意义。我对它的看法是应用程序可以映射到一个包;只是捆绑以某种方式使用其他捆绑包。但是如果要使用Import-Package创建应用程序包，我不会从开发的角度看这是如何可行的。
一种方法可能是使用Require-Bundle并拥有自己的版本的“应用程序包”，但在OSGi世界中，Require-Bundle不受欢迎。
使用Import-Package导入具有所需版本的所有必需软件包，但是，在我认为不可行的情况下，会向开发人员添加重要维护开销。每次进行最小的更改，甚至是实现包，都必须更新包版本，然后在“应用程序包”中更新对包版本的依赖。
答案 0 :(得分：6)
框架是应用程序...... OSGi世界中最大的错误就是将OSGi视为一个多租户框架，它不是为此而设计的，并不适合。在框架内部，有很高的凝聚力，所有注册的服务都是您的服务。 OSGi的架构模型允许您从通过服务连接的松散耦合组件编写应用程序。到目前为止，它在软件中是最好的（尽管很遗憾会有很多缺失的组件会出现）。
在bndtools中，我们会尽力帮助这个模型。 bndtools bndrun文件基本上是一个可以部署的应用程序。 bnd可以将此bndrun文件转换为带有Main-Class清单头的runnable Jar。 （使用JPM，可以很容易地在任何系统上部署。）
因此工作流程基本上是：设计您的服务（==架构），查找标准组件，开发缺少的组件，测试组件，测试集成，并将整个事物转换为可运行的JAR（或WAR）。
显然，如果需要的话，你仍然可以在一个虚拟机中运行多个框架，但是永远不要在同一个框架中运行不同的不相关的应用程序，这不是一个好主意，生活很难实现。
答案 1 :(得分：4)
我认为你要找的是'子系统'，我认为有一个OSGi草案规范。在那里。
我的个人观点：
构建捆绑包并将它们存储在某处（例如Sonatype Nexus服务器，我对它非常满意，它甚至支持OBR以及对生成p2数据的有限支持）
然后，“应用程序”是从该存储库中选择具有特定版本的捆绑包，您可以再次对其进行版本化。
还没有真正的标准，我想在这一点上你需要选择一个非标准的标准。改变标准或甚至支持多个的成本不应该那么好。
These slides提及所有这些
答案 2 :(得分：2)
如果您使用OBR或新R5解析程序等解析程序，则使用Import-Package并不一定会产生大量维护费用。
然而，Require-Bundle方式也是可能的。 “应用程序”通常由少量（例如1-5个）“有趣”的包组成。然后还有其他所有内容，例如依赖项，SCR，蓝图等。因此，您可以创建一个单一的顶级应用程序包，使用Require-Bundle来引用一小组有趣的包，然后所有其他依赖项都是使用Import-Package指定。