Difference between revisions of "OSGi Concepts Bundles"

From CDOT Wiki
Jump to: navigation, search
(Headers)
(version explained)
Line 29: Line 29:
 
# Requirements: Import-Package and/or Require-Bundle (Example: org.osgi.framework;version="1.3.0")
 
# Requirements: Import-Package and/or Require-Bundle (Example: org.osgi.framework;version="1.3.0")
 
# Anatomy: '''Bundle-ManifestVersion, Bundle-Name, Bundle-Activator, Bundle-RequiredExecutionEnvironment'''
 
# Anatomy: '''Bundle-ManifestVersion, Bundle-Name, Bundle-Activator, Bundle-RequiredExecutionEnvironment'''
 +
 +
See [http://www.osgi.org/Specifications/ReferenceHeaders Bundle Headers] for a complete OSGi headers specification.
 +
 +
Version identifier for bundles and packages could have four components.
 +
 +
version format ::= major('.'minor('.'micro('.'qualifier)))
 +
 +
The semantics for the version parts are therefore defined as [http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf]:
 +
* ''major'' -  Packages with versions that have different major parts are not compatible both for providers as well as consumers. For example, 1.2 and 2.3 are completely incompatible.
 +
* ''minor'' - API consumers are compatible with exporters that have the same major number and an equal or higher minor version. API providers are compatible with exporters that have the same major and minor version number. For example, 1.2 is backward compatible with 1.1 for consumers but for providers it is incompatible. Consumers should therefore import [1.2,2) and providers should import [1.2,1.3).
 +
* ''micro'' - A difference in the micro part does not signal any backward compatibility issues. The micro number is used to fix bugs that do not affect either consumers or providers of the API.
 +
* ''qualifier'' - The qualifier is usually used to indicate a build identity, for example a time stamp. Different qualifiers do not signal any backward compatibility issues.

Revision as of 10:28, 20 January 2011

What is a Bundle?

Definitions:

1. A bundle is a component that can be identified, can express its requirements and capabilities and has a specific anatomy.


Bundle = JAR file + MANIFEST.MF file

An example of a MANIFEST.MF

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Book Finder Service
Bundle-SymbolicName: cs.ecl.osgi.simple.bookfinderservice
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: cs.ecl.osgi.simple.bookfinderservice.Activator
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Import-Package: org.osgi.framework;version="1.3.0"
Bundle-Vendor: Seneca College -  Eclipse Course
Export-Package: cs.ecl.osgi.simple.bookfinderservice
Require-Bundle: cs.ecl.osgi.simple.bookfinder;bundle-version="1.0.0"
  1. Indendification: Bundle-SymbolicName & Bundle-Version (Example: cs.ecl.osgi.simple.bookfinderservice & 1.0.0.qualifier)
  2. Capabilities: Export-Package (Example: cs.ecl.osgi.simple.bookfinderservice)
  3. Requirements: Import-Package and/or Require-Bundle (Example: org.osgi.framework;version="1.3.0")
  4. Anatomy: Bundle-ManifestVersion, Bundle-Name, Bundle-Activator, Bundle-RequiredExecutionEnvironment

See Bundle Headers for a complete OSGi headers specification.

Version identifier for bundles and packages could have four components.

version format ::= major('.'minor('.'micro('.'qualifier)))

The semantics for the version parts are therefore defined as [1]:

  • major - Packages with versions that have different major parts are not compatible both for providers as well as consumers. For example, 1.2 and 2.3 are completely incompatible.
  • minor - API consumers are compatible with exporters that have the same major number and an equal or higher minor version. API providers are compatible with exporters that have the same major and minor version number. For example, 1.2 is backward compatible with 1.1 for consumers but for providers it is incompatible. Consumers should therefore import [1.2,2) and providers should import [1.2,1.3).
  • micro - A difference in the micro part does not signal any backward compatibility issues. The micro number is used to fix bugs that do not affect either consumers or providers of the API.
  • qualifier - The qualifier is usually used to indicate a build identity, for example a time stamp. Different qualifiers do not signal any backward compatibility issues.