Application manifest files

The application manifest file contains metadata that enables the OSGi Framework to process the modular aspects of the bundles.

The following code is an example of the contents of an application manifest file:
Manifest-Version: 1.0
Application-Name: OSGi Blog Application
Application-SymbolicName: com.ibm.ws.eba.example.blog.app
Application-Version: 1.0.0
Application-Content: com.ibm.ws.eba.example.blog.api;version=1.0.0,
 com.ibm.ws.eba.example.blog.persistence;version=1.0.0,
 com.ibm.ws.eba.example.blog.web;version=1.0.0,
 com.ibm.ws.eba.example.blog;version=1.0.0,
 com.ibm.json.java;version="1.0.0"
Application-ManifestVersion: 1.0
Application-ImportService: com.ibm.ws.eba.counter.Greet
Application-ExportService: com.ibm.ws.eba.example.blog.api.BloggingService
An application manifest can contain the following headers:
Application-SymbolicName

The unique symbolic name of the OSGi application, using similar package notation to Java™.

Application-Version

The version of the application, using OSGi syntax for a bundle version.

Application-Name

The name of the application.

Application-ImportService

Declares the external dependencies of the bundle that are used by the OSGi Framework for bundle resolution. Specific versions or version ranges for each service can be declared.

A set of filters for external services that the application consumes. The application manifest must contain the classes that services require. If this header is not specified, none of the required services are imported.

Specify the required services in a comma-separated list with the service interface name first followed by attributes or directives.
<service identifier>;<directives>;<attributes>
For example:
test.it;filter="some_filter"
The Application-ImportService header has the following attribute:
filter
An OSGi service filter.
Application-ExportService

Declares the services that are visible outside the bundle. Any service not declared here has visibility only within the bundle.

A set of filters for external services that the application produces. If this header is not specified, none of the required services are exported.

Specify the exported services in a comma-separated list with the service interface name first followed by attributes or directives.
<service identifier>;<directives>;<attributes>
For example:
test.it;filter="some_filter"
The Application-ExportService header has the following attribute:
filter
An OSGi service filter.
Use-Bundle

A shared bundle that provides at least one package to an application bundle.

A list of bundles or composite bundles to use to satisfy the package dependencies of bundles in the Application-Content list. Each bundle or composite bundle in the Use-Bundle list must provide at least one package to at least one bundle in the Application-Content list. These bundles are provisioned into the shared bundle space at run time.

Often, you do not require a Use-Bundle header, but there are some situations where it is useful. You can use it to restrict the level at which sharing is possible. For example, you can ensure that an application uses the same bundle for package imports that it was tested with. Alternatively, you can ensure that two applications use the same bundle for package imports. By setting the restriction at application level, the bundle can remain flexible.

Application-WebModules

List of non-OSGi dynamic web projects that are included in the application.

This header is not part of the OSGi standard.

Application-Content
A list of composite bundles, bundle fragments, and bundles with the acceptable range of OSGi version specifications that are included in the application.
Tip: When including a bundle fragment in the Application-Content list, ensure that you include the host bundle for the fragment.
The format is a comma-separated list of module declarations, where each module declaration uses the following format:
<module identifier>;<directives>;<attributes>

Typically, the module identifier is the symbolic name of a bundle. To reference a resource that is not a bundle, the module identifier is the path relative to the OSGi application root.

The Application-Content header has the following attribute:
version
The version of the module is specified using OSGi syntax for a version range. Specify the minimum version of the application followed by the maximum version to which the application can be upgraded. For example, "[1.0.0,2.0.0)" means version 1.0.0 and all later versions up to, but excluding, version 2.0.0.

The Application-Content header defines the important applications that compose the business services, but it does not define the full list of bundles in the application. If a bundle that is listed in the content uses a package that is not included in the application, a dependency analysis is performed and any missing bundles are included. These bundles cannot provide services external to the application and cannot have security applied to them. Bundles that are included using this mechanism are shared.