The framework, like all software, will mature over time. Changes will be made to improve efficiency, add features, and fix bugs. To ensure that compontents built for
and its sub-frameworks are compatible, developers must be aware when and where they establish dependencies from developed components.
For components written at the Framework level (see Developing at the Framework Level), adhere to the following specifications:
| Standard/Specification | Version | Current Implementation (subject to change) |
|---|---|---|
| OSGi Framework | 4.2 | Apache Karaf 2.x |
| OSGi Enterprise Specification | 4.2 | Apache Aries (Blueprint) |
Avoid developing dependencies on the implementations directly, as compatibility in future releases cannot be guaranteed. |
For components written for the Catalog (see Developing Catalog Components), only dependencies on the current major version of the Catalog API should be used. . Detailed documentation of the Catalog API can be found in the Catalog API Javadocs.
| Dependency | Version Interval | Notes |
|---|---|---|
| [2.0, 3.0) | Major version will be incremented (to 3.0) if/when compatibility is broken with the 2.x API. |
follows the Semantic Versioning White Paper for bundle versioning (see Software Versioning).
It is recommended to avoid building directly on included third party and utility bundles. These components do provide utility (e.g. JScience) and reuse potential, however they may be upgraded or even replaced at anytime as bug fixes and new capabilities dictate. For example, Web services may be built using CXF. However, the distributions upgrade CXF frequently between releases to take advantage of new features. If building on these components, please be aware of the version upgrades with each distribution release.
Instead, component developers should package and deliver their own dependencies to ensure future compatibility. For example if re-using a bundle like commons-geospatial, the specific bundle version that you are depending on should be included in your packaged release and the proper versions should be referenced in your bundle(s).
Always use a version number when exporting a package
<Export-Package>
${project.artifactId}*;version=${project.version}
</Export-Package> |
In the example above the ${project.artifactId} represents the project and artifactId of the package being exported. The ${project.version} represents the version of the project.