从一个源安装多个包

Question

我使用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。那么我的问题是，有没有办法从一个源url创建多个包？

Answer 1

您遇到的问题是，您不能安装具有相同符号名称和版本的包的多个副本。

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

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

Answer 2

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

为此，请执行以下操作：

1. 创建功能文件。更多可以在这里找到：external source
2. Put，该功能文件位于Karaf主目录下的m2 directory.
3. Modify org.apache.karaf.features.cfg中的某个位置。将刚刚创建的特性文件的mvn URL添加到"featuresRepositories“标记中。可选地，将该功能的名称添加到"featuresBoot“如果你想让它在Karaf上加载它们，你可以输入”feature : start-up.
4. After name_of_feature“。这将启动要素以及要素文件定义的要素所需的任何其他内容。

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

希望这能有所帮助。

Answer 3

编辑:刚看到这篇文章已经一年了！Stackoverflow RSS feed把这个放在我列表的最上面!?!

+1's to Marcel & Tony，两者都是正确的。

处于RESOLVED状态的包是活动导出/导入包(ACTIVE意味着服务的任何激活都已经启动和完成)，您应该使用Karaf特性。目前，我们手动使用了karaf- feature文件(请参阅下载版本中的PDF文档)，因为v2.x插件为每个依赖项创建了一个单独的功能，这有点奇怪(我还没有尝试过fixed/v3，但它似乎是主干)

你正在尝试的东西有两个陷阱；

1. pax maven url处理程序命令将识别该捆绑包已安装，并且不执行任何操作
2. 即使它安装了，第二个捆绑包也会失败，因为符号名称很可能与第一个

相同

(最差)选项1:

如果你真的非常想解决这个问题，假设你使用的是maven- bundle -plugin，将buildnumber-maven-plugin和以下代码添加到包配置中：

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

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

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

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

(不那么糟糕)选项2:

稍微更好(并且不需要修改pom.xml)：

请注意bundle

• Invoke

1. refresh命令
2. 的确切时间戳版本，以便回滚、卸载该软件包并安装前面提到的version

有了这个选项，正如Tony所说的，你可以单独管理所有这些包，这是一种痛苦和危险(什么与什么一起工作？这是写在哪里？)。Karaf特性和versions-maven-plugin插件将是更好的解决方案

(好)选项3:

1. 将你的捆绑包一分为二；一个API捆绑包和一个实现捆绑包--这样的话，切换你的实现捆绑包(服务和实际逻辑)不会只影响服务和OSGi版本控制方案，它与maven版本控制有合理的协同作用(参见semantic versioning pdf和Peter Kriens在negative qualifiers上的帖子)。方案是MAJOR.MINOR.MICO.qualifier，其中除了bug fixes
2. SNAPSHOTs之外没有添加新功能的micro numbers应该仅用于开发而不是生产，因为您正在使用未经测试的、可更改的、移动目标(其中您必须使用快照将它们锁定到您通过使用时间戳的版本实际使用的版本(对于第三方依赖，您必须使用快照版本，versions-maven-plugin lock-snapshots目标可以在这里提供帮助)
3. 使用Karaf功能。它使大型捆绑包套件更易于管理(使用一个命令部署您的整个堆栈并进行类似的升级)