3

我使用 Apache Karaf 作为 OSGi 容器。Karaf 有 url 包装器，可以直接从 maven 存储库安装包

> install mvn:com.farpost.billing/background-service/2.2-SNAPSHOT
Bundle ID: 139

一切正常。但我想从给定的来源开始几个捆绑包。如果新捆绑包偶尔会中断生产服务并且我想回滚，这是有道理的。使用 OSGi，这非常简单

 > list 
 [ 139] [Active     ] [            ] [Started] [   60] Billing background service (2.2-20100811-1232)
 [ 140] [Resolved   ] [            ] [       ] [   60] Billing background service (2.2-20100809-1127)
 > update 140
 > list
 [ 139] [Active     ] [            ] [Started] [   60] Billing background service (2.2-20100811-1232)
 [ 140] [Resolved   ] [            ] [       ] [   60] Billing background service (2.2-20100812-1354)
 > start 140
 > stop 139
 > list
 [ 139] [Resolved   ] [            ] [       ] [   60] Billing background service (2.2-20100811-1232)
 [ 140] [Active     ] [            ] [Started] [   60] Billing background service (2.2-20100812-1354)
 #################
 # suppose we need to rollback here
 #################
 > start 139
 > stop 140

问题是我无法从一个来源创建多个捆绑包：

> install mvn:com.farpost.billing/background-service/2.2-SNAPSHOT
Bundle ID: 139
> install mvn:com.farpost.billing/background-service/2.2-SNAPSHOT
Bundle ID: 139

第二次install调用不执行任何操作，但返回已经存在的捆绑包 ID。所以我的问题是，有没有办法从一个源网址创建多个捆绑包？

4

3 回答 3

2

您遇到了无法安装多个具有相同符号名称和版本的捆绑包副本的问题。

即使可以，在您描述的场景中安装同一个包的两个不同版本也会产生副作用，因为只要安装了一个包，它就可以用来解析包。在您的场景中，这可能不是您想要的，因为您想使用一个或另一个捆绑包，而不是混合使用。

最后，我建议您只安装所需的捆绑包。如果它有问题，请通过卸载有问题的捆绑包并安装旧版本来回滚。如果您想自动安装和更新（组）捆绑包，请查看 Apache ACE，这是一个用于 OSGi 的软件供应框架，它将帮助您自动执行此类场景（并在一般情况下管理 OSGi 系统）。

于 2010-08-14T22:02:11.227 回答
2

可以使用功能文件一次安装多个捆绑包。目前，我们有一个特性文件，它定义了大约 6-7 个包。最重要的是，该文件包含一个需要其他 6-7 的功能。通过安装“master”功能，Karaf 同时安装了以下所有捆绑包。如果你愿意，你可以让 Karaf 在启动时运行这些包。

为此：

  1. 创建一个特征文件。更多可以在这里找到：外部来源

  2. 将该功能文件放在 m2 目录中的某个位置。

  3. 修改 Karaf 主目录中的 org.apache.karaf.features.cfg。将 mvn URL 添加到您刚刚创建的功能文件的“featuresRepositories”标签中。或者，如果您希望它在启动时加载它们，请将功能的名称添加到“featuresBoot”。

  4. 启动 Karaf 后，您可以键入“features:install name_of_feature”。这将启动功能以及功能文件定义的功能所需的任何其他内容。

然后，您可以键入 list 以验证所有必需的捆绑包都在运行。这样做的缺点是，如果任何捆绑包发生更改或添加新捆绑包，则需要进行更新。

希望这可以帮助。

于 2011-08-19T16:04:56.267 回答
1

编辑：刚看到这篇文章已经一岁了！Stackoverflow RSS 提要将此放在我的列表顶部！？！

对马塞尔和托尼+1，两者都是正确的。

处于RESOLVED状态的包是活动导出/导入包（ACTIVE表示任何服务激活已启动并完成），您应该使用 Karaf 功能。目前我们手动滚动我们的 karaf-features 文件（请参阅分发下载中的 PDF 文档），因为 v2.x 插件为每个依赖项创建了一个单独的功能并且有点古怪（我没有尝试过 trunk/v3 但它似乎是固定的）

您正在尝试的有两个陷阱；

  1. pax maven url handler 命令将识别出捆绑包已经安装并且什么也不做
  2. 即使这样做了，第二个捆绑包也会失败，因为符号名称很可能与第一个捆绑包相同

（最差）选项 1：

如果您真的很想专门解决这个问题，假设您使用 maven-bundle-plugin，请将buildnumber-maven-plugin添加到捆绑配置中：

<Bundle-SymbolicName>${project.artifactId} ${buildNumber}</Bundle-SymbolicName>

然后，当您安装捆绑包时，请使用显式快照版本（版本名称中的 SNAPSHOT 在概念上只是指向最新时间戳版本的存储库软链接）：

install mvn:com.farpost.billing/background-service/2.2-20100812-1354

使用此选项，正如 Marcel 所述，您可以在从ACTIVE包导入服务时将其他包包导入连接到RESOLVED包 - 因此类不匹配会破坏您的系统。

（不那么糟糕）选项 2：

稍微好一点（并且对 pom.xml 没有任何更改）：

  1. 请注意捆绑包的确切时间戳版本
  2. 调用refresh命令
  3. 要回滚，请卸载捆绑包并安装前面提到的版本

正如托尼所说，使用此选项，您将单独管理所有这些捆绑包，这既痛苦又危险（什么适用于什么？这在哪里写下来？）。Karaf 功能和versions-maven-plugin插件将是一个更好的解决方案

（好）选项 3：

  1. 将您的捆绑包一分为二；一个 API 包和实现包——这样切换你的实现包（服务和实际逻辑）不会影响包连接，只是服务解析
  2. 使用 OSGi 版本控制方案，它与 maven 版本控制具有合理的协同作用（请参阅语义版本控制 pdf和 Peter Kriens 关于否定限定符的帖子）。该方案是 MAJOR.MINOR.MICO.qualifier，其中除了错误修复之外没有添加任何新功能的微数字
  3. SNAPSHOT 应仅用于开发而不是生产，因为您正在使用未经测试的、随时可能更改的移动目标（您必须使用快照将它们锁定到您实际使用过的版本，方法是使用时间戳记）版本（对于第 3 方依赖项，您必须使用 SNAPSHOT 版本，versions-maven-plugin lock-snapshots目标可以在这里提供帮助）
  4. 使用 Karaf 功能，它使大型捆绑包更易于管理（使用一个命令部署整个堆栈并进行类似升级）
于 2011-08-20T17:55:00.283 回答