The following table lists the headers you can add to the manifest template, in addition to the standard manifest headers.
Table 5.1. Headers for Manifest Template
A comma-separated list of packages that must not be added to the manifest's
|By default, Bundlor adds imports for every package that Bundlor determines is referenced by the code or for special files in the jar. Use this header to specify a comma-separated list of packages for which imports Bundlor will not generate.|
By default, Bundlor versions all exported packages at the specified
|If the JAR for which you are generating a manifest already contains an OSGi-compliant manifest, use this template header to list headers in the original manifest which Bundlor should ignore.|
|Use this header to augment package imports that Bundlor generates via bytecode and special file analysis. Typically you use the header to version the import and, in some cases, to mark them as optional. When you use this header to version the import, you can optionally specify a version expansion pattern so that Bundlor sets the version to a range rather than a single version. To use the header, set its value to a comma-separated list of package names and attributes.|
Use this header to declare one or more version expansion patterns and give each one a name.
You can then use these named patterns in the |
A wilcard '
*' at the end of the package name is supported to match multiple packages. For
example, the header
will cause any import generated for the
com.foo package to be versioned at 1.0
(inclusive) to 2.0 (exclusive) and to be considered optional, and for any import of
com.bar or its sub-packages to be versioned at 1.5 (inclusive) to 1.6 (exclusive).