...
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.
...
| 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.
...
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:
...
- 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.