在先前的文章, 我就怎样使用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安装位置的全局配置文件：未使用。

• $HOME/.m2指定的Maven settings.xml：默认。

• Karaf分发版的默认仓库：默认；修改请慎重。

• 内建仓库：可用，但是被配置文件覆盖。

• org.ops4j.pax.url.mvn.cfg配置：一直使用，可以指定是否使用其他仓库。

最后，我发现，在联网环境下，可以在列表最后追加一个新仓库，这样很容易就能忽略上面那些配置；在无网环境下，我们可以用一个可用的Maven仓库替换这个列表。

虽然写了这么多，我仍然希望能用一个简单的例子，讲到编写Karaf特性仓库XML文件的一些最佳实践。