Java 从一个源安装多个捆绑包

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

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

一切正常。但我想从给定的源开始几个bundle。如果新捆绑包偶尔会破坏生产服务，并且我想回滚，那么这是有意义的。对于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

call除了返回已经存在的bundle id之外什么都不做。所以我的问题是，有没有办法从一个源url创建多个bundle？

您遇到了一个问题，即不能安装多个具有相同符号名称和版本的bundle副本

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

---

最后，我建议您只安装您想要的捆绑包。如果存在问题，请通过卸载有故障的捆绑包并安装旧版本来回滚。如果您想自动安装和更新（一组）捆绑包，请查看ApacheACE，这是一个OSGi的软件配置框架，它将帮助您自动执行这些场景（并通常管理OSGi系统）。

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

为此，请执行以下操作：

创建要素文件。更多信息可在此处找到：

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

在karaf主目录中修改org.apache.karaf.features.cfg。将mvn URL添加到刚刚创建的功能文件中的“featuresRepositories”标记中。如果希望在启动时加载特性，可以选择将特性的名称添加到“featuresBoot”

启动Karaf后，可以键入“功能：安装功能的名称”。这将启动功能以及功能文件定义的功能所需的任何其他内容

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

---

希望这有帮助。

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

+马塞尔和托尼各说一句，两个都对

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

你所尝试的有两个陷阱

paxmavenurl处理程序命令将识别捆绑包已经安装，并且不执行任何操作

即使这样，第二个包也会失败，因为符号名称很可能与第一个包相同

（最差）选项1:

如果您真的非常想解决这个问题，假设您使用maven bundle插件，请将和添加到bundle配置中：

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

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

（不太坏）选项2:

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

请注意捆绑包的确切时间戳版本

调用

refresh

命令

要回滚，请卸载该捆绑包并安装以前提到的版本

正如Tony所说，使用此选项，您将单独管理所有这些捆绑包，这既痛苦又危险（什么与什么一起工作？这写在哪里？）。Karaf功能和插件将是一个更好的解决方案

（好）选项3:

把你的包裹一分为二；API捆绑包和实现捆绑包——这样，关闭实现捆绑包（服务和实际逻辑）不会影响包的连接，只会影响服务解决方案

使用OSGi版本控制方案，它与maven版本控制具有合理的协同作用（请参阅和Peter Kriens的文章）。该方案是MAJOR.MINOR.MICO.qualifier，其中的micro编号除了修复bug之外没有添加任何新功能

快照应仅用于开发，而不用于生产，因为您使用的是未经测试、可能会发生更改的移动目标（您确实必须使用快照），通过使用时间戳版本将快照锁定为您实际使用的版本（对于必须使用快照版本的第三方依赖项，此处的目标可能有所帮助）

使用Karaf特性，它使大型捆绑包套件更易于管理（使用一个命令部署整个堆栈，并进行类似的升级）

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