...
Bundle is an OSGi Alliance term for a module in an OSGi Service Platform. A Bundle is packaged as a regular jar file with additional entries in its manifest. Every jar file in the repository is a valid OSGi bundle and can be deployed as-is into an OSGi Service Platform and the SpringSource dm Server. Bundles in the repository all define the following information:
- Bundle-Name: the human-readable name of the bundle, for example, "Spring Core".
- Bundle-SymbolicName: a string that (along with the version information) uniquely identifies the bundle. Symbolic names follow reverse domain-name conventions - for example, "org.springframework.core".
- Bundle-Version: the version of the bundle, e.g. 2.5.4
- Export-Package: the packages exported by the bundle. In OSGi only packages that are exported by the bundle are visible to other bundles. Packages that are not exported remain private to the bundle. When searching the repository for bundles providing certain classes or resources, only the exported packages are displayed and searched. Every package is exported with version information, for example, the Spring Core bundle, version 2.5.4 exports version 2.5.4 of the org.springframework.core package.
- Import-Package: the package-level dependencies of the bundle. These may be optional or mandatory dependencies. Each import specifies the version range it is compatible with (e.g. "version 2.5.0 or higher").
Where to find
...
existing bundles
Most of the libraries we use currently are available on the SpringSource Enterprise Bundle Repository and can be retrieved by Ivy.
Wrapping jar files into OSGi bundles
For the libraries that are not available as OSGi bundles, we need to create the bundle on our own. The tool that can help is Bnd. In the attachment of the page there is bnd-1.50.0.jar that can be used to generate the OSGi bundles from the existing jars via command line:
| Code Block |
|---|
java -jar bnd.jar wrap -properties bnd_properties.bnd [source/path/toof/theyour/jar/filelibrary.jar] |
The content of the bnd properties file is as follows:
...
The bnd_properties.bnd file above was used to wrap the spring-aop-3.2.16.RELEASE.jar file into an OSGi bundle. You have to modify the value of version (line 1) and artifact (line 2) to match your particular case. Leave the other lines untouched to ensure that your library is wrapped according to our guidelines.
...
Use the values you specified in your bnd properties file to replace ${artifact} and ${version} in the table above.
Specifying dependencies
...
| Info | ||
|---|---|---|
| ||
|
Specifying dependencies
In the manifest for the Commons, CommonsCS and inspectIT projects we list all required plug-ins as a dependency via Required Plug-ins option.
...
All the OSGi bundles we retrieve via Ivy will be placed in the ${project_loc}/lib/osgi inspectit.root/build/updatesite folder. However, when an Eclipse plug-in is run from the Development environment, we need to have those plug-ins available in the Eclipse/plugins/ folder. Since it is complicated for developer to constantly update the plugin folder of Eclipse installation manually, we have created the Target Definition for inspectIT RCP where all needed plug-ins are defined.
The definition file is inspectit.root/resources/target/inspectIT.target and defines four places as the source of required plug-ins for execution:
- Commons/lib/osgi folder
- CommonsCS/lib/osgi folder
- inspectit/lib/osgi folderinspectit.root/build/updatesite
- Eclipse Indigo update site with plug-ins defined for Eclipse platform and Eclipse Platform SDK located under inspectit.root/build/eclipse
Support for Java 1.8
Since Eclipse Indigo does not support Java 1.8, we have manually added JavaSE-1.8 profile to the needed jar (described https://stackoverflow.com/questions/24669940/java-8-missing-required-capability-require-capability-osgi-ee-filter-osg) and updated the patched Eclipse base to the Nexus under version 3.8.2_20170531. This is why target definition must point to the updated base and the update site for the Eclipse Indigo can not be used.