简介

最近，Bundlor 的 M3 里程碑已发布 (论坛公告)。此里程碑增加了对属性替换和版本扩展的支持。 这篇博客文章解释了如何使用这些新功能来提高生成的 Manifests 的质量。

属性替换

现在可以使用 Bundlor 将任何属性值替换到您的 Manifest 模板中。

Bundle-Name: ${name}
Bundle-Description: Test bundle using new version of Kernel at ${com.springsource.kernel}
Import-Template: com.springsource.kernel.*;version="${com.springsource.kernel}"

此语法允许您为 ${name} 和 ${com.springsource.kernel} 指定属性占位符，并在运行时将其替换为实际值。 这些值的传入方式取决于使用的 Bundlor 前端。

在命令行中指定属性

当 Bundlor 从命令行运行时，它将使用所有可用的属性作为系统属性，这不包括任何环境变量。 命令行脚本将传递通过 -D 传入的任何变量，因此以下命令将为 ${com.springsource.kernel} 属性提供值 '2.0.0.RELEASE'，并为 ${name} 属性提供值 'Kernel test bundle'。

bundlor.sh \
        transform \
        --bundle ./org.springframework.integration.jar \
        --manifest ./template.mf \
        --outputfile ./target/org.springframework.integration.jar \
        -Dcom.springsource.kernel=2.0.0.RELEASE \
        -Dname="Kernel test bundle"

使用 Maven 指定属性

要将属性从 Maven 构建传递到 Bundlor 中，您应该在 Maven 项目文件的 project 元素下定义一个新的（或添加到现有的）properties 元素。

<properties>
    <name>${project.name}</name>
    <com.springsource.kernel>2.0.0.RELEASE</com.springsource.kernel>
</properties>

这将运行 Bundlor，其中 ${com.springsource.kernel} 的替换值为 '2.0.0.RELEASE'，${name} 的替换值为 Maven 项目的名称。

使用 Ant 指定属性

从 Ant 调用 Bundlor 任务时，可以在任务上提供一个额外的属性，该属性传入一个 Ant 属性集，该属性集将传递给 Bundlor。

<bundlor:bundlor>
    bundlePath="${basedir}/org.springframework.integration.jar"
    outputPath="${basedir}/target/org.springframework.integration.jar"
    bundleVersion="2.0.0.BUILD-${timestamp}"
    manifestTemplatePath="${basedir}/template.mf">
    <propertyset>
        <property name="name" value="${ant.project.name}"/>
        <property name="com.springsource.kernel" value="2.0.0.RELEASE"/>
    </propertyset>
</bundlor:bundlor>

这将运行 Bundlor 并为 ${com.springsource.kernel} 提供 '2.0.0.RELEASE' 的替换值，并为 ${name} 提供 Ant 项目名称的替换值。

版本扩展

属性替换可以发生在 Manifest 模板值的任何位置。 它甚至可以用于替换“Import-Template”版本。 就其本身而言，导入中的单个版本用处不大，因为它相当严格，但是自动将版本扩展为版本范围很有用。可以在冒号后给出版本扩展模式，该模式将应用于版本以生成版本范围。

Import-Template: com.springsource.kernel.*;version="${com.springsource.kernel:[=.=.=.=, +1.0.0)}",
 org.apache.commons.logging.*;version="${org.apache.commons.logging:[=.=.=.=, =.=.+1)}"

版本扩展适用于包含合法 OSGi 版本号的变量。 基于该版本号，扩展分为 4 个部分：major、minor、micro 和 qualifier。 如果提供的属性不是有效的 OSGi 版本，则 Bundlor 将失败，并出现异常，指出提供的属性不是有效的版本字符串。

此版本号的前三个段可以在扩展中替换如下
=	等于变量中的值
[+/-]n	将变量中的值调整此数量
n	用此值替换变量中的值。 这通常仅用于放入 0
第四段（qualifier）只能采用以下替换
=	等于变量中的值
任何合法的 qualifier 值。	用此值替换变量中的值

因此，对于上面的示例，${com.springsource.kernel} 的生成版本范围和给定的 1.2.0 版本将为 [1.2.0, 2.0.0)。 这意味着将使用从 1.2.0 到（但不包括）2.0.0 的最高可用版本。 对于 ${org.apache.commons.logging} 和给定的 1.4.0 版本，生成的版本范围将为 [1.4.0, 1.4.1)，这更加严格，因为它只会允许对版本 1.4.0 的 qualifier 进行更改，而不会允许使用来自 1.4.1.xxx 及以上的版本。

命名

如果要为多个导入使用模式，则可以使用名称指定该模式并多次使用。 在 Template Manifest 中使用一个新的标头来指定命名的版本扩展模式。

Import-Template: 
 org.apache.commons.codec.*;version="${org.apache.commons.codec:apache}",
 org.apache.commons.logging.*;version="${org.apache.commons.logging:apache}",
 org.hibernate.*;version="${org.hibernate:hibernate}"
 org.myorg.*;version="${org.myorg:(=.=.=.=, =.+1.0.=]}"

Version-Patterns: 
 apache;pattern="[=.=.=.=, +1.0.0)",
 hibernate;pattern="[=.=.=.=, =.=.+1)"

这显示了正在定义的多个模式，并用于多个导入。 apache 模式将给出从提供的版本到但不包括下一个主版本的版本范围。 hibernate 模式将给出从提供的版本到但不包括下一个微版本的版本范围。 还有一个使用内联版本扩展模式定义的导入，可以在同一模板中与命名模式一起使用。 内联模式显示了更不寻常的用法。 它将创建一个从（但不包括）提供的版本到（包括）具有相同 qualifier 的下一个次要版本的版本范围。

结论

通过一起使用这些技术，可以生成可靠的 manifests。 正确使用版本扩展将确保生成的 manifests 足够严格以阻止不需要的连接，但又足够灵活以允许进行小的更改。 编写 Template Manifest 时，应针对每个相关 bundle 采取务实的方法，因为并非所有 bundle 都使用相同的方法进行版本控制。