领先一步
VMware 提供培训和认证,以加速您的进步。
了解更多最近发布了 Bundlor 的 M3 里程碑版本(论坛公告)。此里程碑版本增加了对属性替换和版本扩展的支持。这篇博文解释了如何使用这些新功能来提高生成清单的质量。
Bundlor 现在可用于将任何属性值替换到您的清单模板中。
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 构建中将属性传递到 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 调用 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 项目的名称。
属性替换可以在清单模板值的任何位置发生。它甚至可以用来替换“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 部分:主版本、次版本、微版本和限定符。如果提供的属性不是有效的 OSGi 版本,则 Bundlor 将失败并抛出异常,指出提供的属性不是有效的版本字符串。
此版本号的前三个部分可以按如下方式替换扩展: | |
= | 等于变量中的值 |
[+/-]n | 将变量中的值调整此数量 |
n | 用此值替换变量中的值。这通常仅用于输入 0 |
第四部分(限定符)只能采用以下替换: | |
= | 等于变量中的值 |
任何合法的限定符值。 | 用此值替换变量中的值 |
${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 的限定符,并且不允许使用来自 1.4.1.xxx 及以上版本的版本。如果要将模式用于多个导入,则可以使用名称指定它并多次使用。模板清单中使用新的标题来指定命名的版本扩展模式。
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 模式将提供从提供的版本到但不包括下一个微版本的版本范围。还定义了一个使用内联版本扩展模式的导入,该模式可以与同一模板中的命名模式一起使用。内联模式显示了更不寻常的用法。它将创建一个从提供的版本开始但不包括提供的版本,到包括具有相同限定符的下一个次版本的版本范围。
结合使用这些技术,可以生成可靠的清单。正确使用版本扩展将确保生成的清单具有足够的限制性以阻止不需要的连接,但又足够灵活以允许进行细微的更改。在编写模板清单时,应针对每个相关的捆绑包采取务实的做法,因为并非所有捆绑包都使用相同的方法进行版本控制。