The following shows a simple example of a Bundlor manifest template file, with a description after the sample.
Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.springframework.binding Bundle-Name: ${bundle.name} Bundle-Vendor: SpringSource Import-Package: ognl;version="[2.6.9, 3.0.0)";resolution:=optional, org.jboss.el;version="[2.0.0, 3.0.0)";resolution:=optional Import-Template: org.springframework.*;version="[2.5.4.A, 3.0.0)", org.apache.commons.logging;version="[1.1.1, 2.0.0)", javax.el;version="[2.1.0, 3.0.0)";resolution:=optional, ognl;version="[2.6.9, 3.0.0)";resolution:=optional, org.jboss.el;version="[2.0.0, 3.0.0)";resolution:=optional
The headers marked in bold are required in all manifest templates unless the jar already contains a manifest with those headers.
Bundle-ManifestVersion: This should always be 2Bundle-SymbolicName: specifies a unique name for the bundle of
org.springframework.bindingBundle-Name: specifies a human-readable name for the bundle. The example shows how to
use a property placeholder ${bundle.name}, which at runtime Bundlor will substitute
with an actual value, such as Spring Binding.
Bundle-Vendor: specifies the bundle's vendorImport-Package: hard-codes two packages that will be imported (
ognl and org.jboss.el in the generated manifest. Bundlor isn't
infallible; this lets you add imports that it misses.
Import-Template: specifies the versions for the package imports that Bundlor
generates, marking javax.el, ognl, and
org.jboss.el optional.