11

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

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

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

Eclipse 有一个称为“功能”的概念，但这不是 OSGi 标准。

Peter Kriens写过关于 OSGi 应用程序的文章，他的文章很有道理。我从中得出的结论是，应用程序可以映射到捆绑包。只是捆绑包以某种方式使用了其他捆绑包。但是，如果要使用 Import-Package 创建应用程序包，从开发的角度来看，我不认为这是可行的。

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

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

4

3 回答 3

6

框架就是应用程序……恕我直言，OSGi 世界中最大的错误是将 OSGi 视为多租户框架，它不是为此目的而设计的，也不适合。在一个框架内部，有很高的内聚性，所有注册的服务都是你的服务。OSGi 的架构模型允许您从通过服务连接的松散耦合组件编写应用程序。恕我直言，到目前为止，它在软件中是最好的（尽管不幸的是，会有很多缺失的组件会出现）。

在 bndtools 中，我们竭尽全力帮助这个模型。bndtools bndrun 文件基本上是您可以部署的应用程序。bnd 可以将此 bndrun 文件转换为带有 Main-Class 清单头的可运行 Jar。（并且使用 JPM，它可以很容易地部署在任何系统上。）

所以工作流基本上是：设计你的服务（==架构），找到标准组件，开发缺失的组件，测试组件，测试集成，然后把整个东西变成一个可运行的 JAR（或 WAR）。

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

于 2012-07-04T17:17:30.397 回答
4

我认为您正在寻找的词是“子系统”，我认为有一个 OSGi 草案规范。在那里。

我个人的看法：

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

然后，“应用程序”是从该存储库中选择具有特定版本的捆绑包，您可以再次对其进行版本控制。

目前还没有真正的标准，我认为此时您需要选择其中一个非标准的标准。更改为标准版本甚至支持多个版本的成本应该不会那么高。

这些幻灯片提到了所有这些

于 2012-07-04T10:17:36.707 回答
2

如果您使用 OBR 之类的解析器或新的 R5 解析器，则使用Import-Package不一定会产生大量维护开销。

不过，Require-Bundle方法也是可以的。一个“应用程序”通常由少量（例如 1-5 个）“有趣的”捆绑包组成。然后是所有其他依赖项，例如依赖项、SCR、蓝图等。因此，您可以创建一个顶级应用程序包，用于Require-Bundle引用一小部分有趣的包，然后所有其他依赖项都使用Import-Package.

于 2012-07-04T10:18:31.883 回答