英文原文：
Apache Karaf Features at Startup
在先前的文章, 我就怎样使用Apache Karaf的“特性”以简单将OSGi包（bundle）添加到一个容器中（包括处理依赖）进行过简述。
就像在文章中所讨论的那样, 就Karaf的“特性仓库”而言有自身的XML格式，它是一个列出了一个或多个新特性的XML文件。其中每个特性列出了其依赖的包含版本支持的特性或包（bundle)。之所以这些能够运作，是因为Karaf可以从（包括Maven在内的）不同的源获取特性仓库的XML文件及其OSGI包。
上次我演示了一行命令从Maven中新建一个属性仓库的XML文件，然后通过命令安装了一个属性。然而，当在生产环境中使用Karaf时，我们当然需要在启动的时候使之加载合适的属性。
Karaf 性能配置
为了实现Karaf特性，我们会更新一些etc/目录下的Karaf配置文件，第一个需要更新的文件是org.apache.karaf.features.cfg。这个文件包含两个相关设置：featuresRepositories和featuresBoot。
featuresRepositories的输入是一个可以被检索的URLs列表的特征库文件。正如我们上次说的，Karaf用“特征库”映射具有一个或多个特征的XML文件。这种“特征库”的XML文件可以依赖一个Web服务器上的文件系统，或（最常见）在maven仓库的文件。（在这里的名字有点重叠）。
为了使Karaf能够在启动时将Apache Camel添加到特征库的列表，我们只是增加一项列表：
featuresRepositories =
mvn:org.apache.karaf.features/spring/4.0.7/xml/features,
mvn:org.apache.karaf.features/framework/4.0.7/xml/features,
mvn:org.apache.karaf.features/enterprise/4.0.7/xml/features,
mvn:org.apache.karaf.features/standard/4.0.7/xml/features,
mvn:org.apache.camel.karaf/apache-camel/2.18.0/xml/features
最后一行是唯一新增的（与前一行上的反斜杠是为了其为有效的java文件）。这个Maven坐标告诉Karaf到哪找到Camel的特征库的XML文件。Karaf建立在足够的Maven支持使其能够在配置Maven库列表中找到该文件。
就其本身而言，这不会使Karaf需要另外安装任何东西；我们还需要为featuresboot添加一个或多个特征。这是一个逗号分隔的功能列表，在启动时安装；所有捆绑的功能也将启动（如果可能的话）。
寻找依赖功能
如果你看一下Karaf 的功能库的XML文件，你就会注意到它只是为绑定包列出了Maven库位置，而不是为任何依赖的功能。依赖功能只是通过名称列出来。
然而，也可以用一个功能文件为依赖的功能指定额外的功能库位置。例如，Camel功能库XML文件中的配置：
<repository>mvn:org.apache.cxf.karaf/apache-cxf/3.1.7/xml/features</repository>
<repository>mvn:org.apache.jclouds.karaf/jclouds-karaf/1.9.2/xml/features</repository>
<repository>mvn:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features</repository>
当库添加到功能库列表时，这些库会被立即添加；Karaf 不会等到功能安装时才添加。不只是这些，Karaf还会立马去取功能库的XML文件，去查找哪些功能是可用的。
潜在的混乱
随着时间的推移，我不得不使用这个不太像期望的那样友好或完整的功能库XML文件。特别是，它们只是列出来功能依赖，但没有列出查找这些功能的库。
为了解决这个问题，我们不得不在Karaf 配置中的featuresRepositories列表中增加功能库，现在，Karaf 就拥有了一个查找功能所有位置的综合列表。但是，这部分很混乱。由于它们将会做为一个依赖被拉取进来，因此也不一定要在featuresBoot中添加它们。这对新人来说是混乱的源泉，因为他们会看到在列表中的功能XML文件的位置，却没有在项目启动时启动的功能列表中看到它， 而觉得这是个问题。
配置Maven
还有一个极其重要的文件，这个文件为Karaf配置按正确的顺序查找并安装功能和捆绑包的配置：org.ops4j.pax.url.mvn.cfg。从名称就知道，这个文件配置了从OPS4J到正确的处理Maven URL的Pax URL .
Pax URL和任何安装了的Maven有一个有趣的关系。它不要求安装Apache Maven ；必要的代码已经嵌入发布的Karaf 中。但是，它默认的使用了每一个Maven用户在$HOME/.m2/settings.xml的设置文件和每一个用户在$HOME/.m2/repository的本地库
虽然每个Maven安装程序（如Maven Central）都提供了可用的Maven仓库，但是默认情况下，它并没有显式使用这些“回退(fallback)”仓库。相反，它拥有自己内建的仓库列表。然而，配置文件没有使用代码中内建的仓库列表，它只使用了配置文件中指定的仓库列表。因此，列表包括Maven Central，所以这个差别不怎么重要。但是如果更改了org.ops4j.pax.url.mvn.cfg配置文件，差别就非常重要了。
更糟的是，配置文件同时按照目录格式列出了Karaf安装位置内的仓库作为defaultRepositories，这种方式甚至覆盖了$HOME/.m2指定的本地Maven仓库。
这很容易混淆，所以总结一下：
最后，我发现，在联网环境下，可以在列表最后追加一个新仓库，这样很容易就能忽略上面那些配置；在无网环境下，我们可以用一个可用的Maven仓库替换这个列表。
虽然写了这么多，我仍然希望能用一个简单的例子，讲到编写Karaf特性仓库XML文件的一些最佳实践。
本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。
2KB翻译工作遵照
CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
