Enterprise bundle archives

An enterprise bundle archive (EBA) file contains a set of OSGi bundles that are deployed as a single OSGi application, and that are isolated from other OSGi applications.

Each OSGi application runs in its own isolated OSGi framework instance with its own OSGi service registry. Bundles in one OSGi application cannot see bundles, services, or packages that are defined in another OSGi application, unless the bundles, services, or packages are explicitly shared by both applications.

The bundles that are used by the OSGi application are either directly contained in the EBA file, or pulled in by reference from an OSGi bundle repository when the application is provisioned. Application metadata stored in the EBA file defines the isolation scope of the bundles that the OSGi application uses.

An EBA file is packaged as a single compressed archive file with a .eba file extension. It can contain an application manifest, and a set of application modules. An application module can be one of the following types of resource:
  • An OSGi bundle, packaged as a Java™ archive (JAR) file.
  • A composite bundle, packaged as a composite bundle archive (CBA) file.
  • A web application, packaged as a web application archive (WAR) file.
Application modules are contained in the root of the EBA file. These modules are directly contained in the OSGi application, whereas all other bundles are provided by reference.

An OSGi application can also use metadata to permit some of its constituent bundles to be shared. Sharing in this way can reduce the memory and resource requirements of a system. Shared bundles must be provided by reference rather than contained directly in an application.

An OSGi application can also load packages and consume OSGi services from a shared bundle space, that is, from the OSGi framework instance that is the parent of all the isolated framework instances of the OSGi applications.

Application manifest

The OSGi bundles in an EBA file share services with other OSGi applications by declaring them in an application manifest file, META-INF/APPLICATION.MF. Any external services and references that the OSGi application produces are exposed by declaring them in the manifest, and any external services and references that the application consumes are also declared in the manifest.

The application manifest specifies the bundles that form the primary content of the application. A bundle that is listed in the primary content might use a package that is not included in the application, and therefore require other bundles to be pulled in. The application manifest might also specify an allowed version range for some bundles; this range defines the initial version of the application, and the latest version to which it can be upgraded.

Optionally, you can explicitly declare shared bundles on which the primary application content depends so that you can restrict the level at which sharing is possible; for example, you can ensure that the application uses a shared bundle only between a specified version range. For more information, see the description of the "Use-Bundle" header in Example: OSGi application manifest file.

An EBA file does not have to contain an application manifest file. The contents of the EBA file is used in two different ways, depending on whether you have included an application manifest, and on whether an Application-Content header is defined in the application manifest:
  • If an Application-Content header is not defined, or there is no application manifest, the EBA file content defines the OSGi application content.
  • If an Application-Content header is defined, the EBA file content defines an initial bundle repository from which bundles can be provisioned.

See Example: OSGi application manifest file.

Deployment manifest

A deployment manifest file, META-INF/DEPLOYMENT.MF, is created automatically when you import an EBA asset. The deployment manifest file lists, at specific versions, all the bundles and composite bundles that make up the application, including bundles that are determined following dependency analysis. The manifest file is used to ensure that each time an application server starts, the bundles that make up the application are the same.

You can export the current deployment manifest from an EBA asset, then import the deployment manifest into another asset that contains the same application. The target asset then uses the imported manifest instead of the generated manifest. This is useful during application development, when an application is fully tested and moves to a production environment. By importing the deployment manifest from the test environment, you ensure that the bundles and their versions that make up the application in the production environment are exactly the same as the bundles that make up the application in the test environment.

See OSGi deployment manifest file and Exporting and importing a deployment manifest file.