Commons OSGi
The purpose of this page is to record progress in Commons of OSGi-enabled releases and any notes on specific issues with configuration of the OSGi manifest entries.
The Apache Felix project (an OSGi implementation) have requested that Commons components include OSGi meta data in their jars so that they are The \[http://felix.apache.org/ Apache Felix\] project have \[http://commons.markmail.org/message/36xoo2bo5aabvy5c requested\] that Commons components include \[http://www.osgi.org/ OSGi\] meta data in their jars so that they are 'ready-to-use' in an OSGi environment. This involves OSGi entries in the jar's manifest file. Wiki Markup Wiki Markup
The Felix project has developed a \[http://felix.apache.org/site/developed the maven-bundle-plugin-bnd.html Maven Plugin\] which makes this easier (_version 1.2.0 released Jan '08_). Before that was released a number of components (Pool 1.4, FileUpload 1.2.1 and IO 1.4) were manually configured with OSGi manifest entries.The purpose of this page is to record progress in Commons of OSGi-enabled releases and any notes on specific issues with configuration of the OSGi manifest entrieseasier and this is now configured in the commons-parent
pom.xml (since version 9) with default instructions. For components which need to override the default instructions, this can be done using properties in the component pom (see below for more details).
SpringSource Bundle Repository
The SpringSource Enterprise Bundle Repository contains a collection of open source libraries and each jar file in the repository is a valid OSGi bundle. This includes a number of re-packaged Commons components, so if you require a component that has not yet been released as an OSGi bundle, you may find it in the SpringSource repository.
N.B. As of writing (May 2008) the status of SpringSource repository is BETA.
Proper
Component | Last Release | First OSGi release | Notes / Comments | ||
attributes | 2.2 |
| No m2 build | ||
beanutils | 1.7.0 | 1.8.0 -BETA |
|
| |
betwixt | 0.8 |
|
| ||
chain | 1.1 |
| 1.2 | ||
cli | 1.1 | 1.2 |
| ||
codec | 1.3 | 1.4 |
| ||
collections | 3.2 | 3.2.1 | Felix Bundle doesn't import org.apache.commons.collections.* - asked on dev@felix | ||
compress | 1.0 |
| |||
configuration | 1.5 |
| 1.6 | Felix Bundle uses alot of dynamic import | |
daemon | 1.0.1 |
|
| ||
dbcp | 1.2.2 | 1.3 |
| ||
dbutils | 1.1 | 1.2 |
| ||
digester | 1.8 |
| 1.8.1 | Felix Bundle does dynamic import of org.apache.commons.logging.impl | |
discovery | 0.4 |
|
| ||
el | 1.0 |
|
| ||
1.1 | 1.2 |
|
| ||
exec | 1.0 | <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="bf1868a4-e62a-4197-b559-ecbbdd452a9b"><ac:plain-text-body><![CDATA[ | |||
fileupload | 1.2 | 1.2.1 (m2,manual) | [http://felix.markmail.org/message/tgm45au3rpmpmfnf javax.portlet]]]></ac:plain-text-body></ac:structured-macro> | ||
io | 1.3.2 | 1.4 (m2,manual) |
| ||
jci | 1.0 |
|
| ||
jelly | 1.0 |
| No m2 build | ||
jexl | 1.1 | 2.0 |
| ||
jxpath | 1.2 |
|
| 1.3 | See Felix Bundle <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e2902104-6bb5-4e8b-ac31-5359b31208b4"><ac:plain-text-body><![CDATA[ |
lang | 2.3 |
| Lang 2.4 looks imminent, see [https://issues.apache.org/jira/browse/LANG-402 LANG-402] | ]]></ac:plain-text-body></ac:structured-macro> | |
launcher | 1.1 |
|
| ||
logging | 1.1.1 |
| OSGi is N/A; See Below | ||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="73d0e0f6-02d2-492b-a95f-df7236a343fc"><ac:plain-text-body><![CDATA[ | math | 1.1 | 1.2 (m2,manual) | See [https://issues.apache.org/jira/browse/MATH-180 MATH-180] | ]]></ac:plain-text-body></ac:structured-macro> |
modeler | 2.0.1 |
|
| ||
net | 1.4.1 | 2.0 |
| ||
pool | 1.3 | 1.4 (m1, manual) |
| ||
primitives | 1.0 |
|
| ||
proxy No yet released | n/a | 1.0 (m2, bundle plugin) |
| ||
scxml | 0.7 | 0.8 |
| ||
transaction | 1.2 |
|
| ||
validator | 1.3.1 |
| Felix Bundle has org.apache.oro.*;resolution:=optional | ||
vfs | 1.0 |
|
|
Commons Logging
...
The things that commons-logging does with classloaders in order to try and work in various servlet engine configurations are not compatible with the classloaders that OSGi environments set up. Therefore adding OSGi attributes to commons-logging is not useful, as commons-logging is not usable in an OSGi environment. See \[http://commons.markmail.org/message/kdnjlbokvuiigcew this thread\] and \[http://wiki.ops4j.org/display/dokuwiki/doku.php?id=pax:logging Pax-logging\]
Configuring OSGi with Maven2
There are two ways to do this:
...
Having said that the Felix project has a bundle to re-package logging - see here
Configuring Commons Components for OSGi with Maven1
This can be done by specifying appropriate manifest entries for the jar plugin (Pool 1.4 is an example) - however it is much easier using maven2 and the maven-bundle-plugin
...
.
...
Configuring Commons Components for OSGi with Maven2
The latest version
...
N.B version 8 of the commons-parent pom includes configuration for the felix bundle plugin which should be sufficient for most components. To use that a component needs to do the following:
- use version 9 of commons-parent
- specify
<packaging>bundle</packaging>
- add a property with the component's name in lower case
Felix's Maven2 Bundle Plugin
To configure the plugin, specify a
No Format |
---|
<packaging>bundle</packaging> |
element in the pom and configure the plugin in the
No Format |
---|
<build> |
section, for example for Commons Lang
configures the maven-bundle-plugin's instructions using properties in the following way:
No Format |
---|
No Format |
<plugin><instructions> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <version>1.2.0</version> <extensions>true</extensions><!-- stops the "uses" clauses being added to "Export-Package" manifest entry --> <configuration> <excludeDependencies>true</excludeDependencies> <_nouses>true</_nouses> <instructions> <Bundle-SymbolicName>orgSymbolicName>${commons.apache.commons.lang<osgi.symbolicName}</Bundle-SymbolicName> <Export-Package>*;version=${pom.versionPackage>${commons.osgi.export}</Export-Package> </instructions> </configuration> </plugin> |
Notes:
<extensions>true</extensions>
needs to be specified otherwise the
is not recognized and causes an error with the message Cannot find lifecycle mapping for packaging 'bundle*_No Format <packaging>bundle</packaging>
<excludeDependencies>true</excludeDependencies>
prevents all the component's dependencies classes being included in the jar- Other_* Manifest_* entries are inherited from the commons-parent pom
- Depending on the nature/structure of the project, some packages might contain private classes that are not meant to be used by client code. In these cases,
<Export-Package>
should list all public packages while<Private-Package>
should contain the private packages.
Configuring via the jar plugin
No Format |
---|
<Private-Package>${commons.osgi.private}</Private-Package> <plugin> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifestEntries> <Bundle-SymbolicName>org.apache.commons.lang</Bundle-SymbolicName><Import-Package>${commons.osgi.import}</Import-Package> <Bundle-License>http://www.apache.org/licenses/LICENSE-2.0.txt</Bundle-License><DynamicImport-Package>${commons.osgi.dynamicImport}</DynamicImport-Package> <Bundle-ManifestVersion>2</Bundle-ManifestVersion> <Bundle-Name>Apache Commons Lang Bundle</Bundle-Name> <Bundle-Vendor>${project.organization.name<Bundle-DocURL>${project.url}</Bundle-Vendor> DocURL> <Bundle-Version>${project.version}</Bundle-Version></instructions> |
This allows component poms to easily override the default values, by specifying alternative values for these properties in their pom. The default values for these properties in commons-parent are:
No Format |
---|
<properties> <Export-Package> org.apache.commons.lang;version=${project.version}, org.<commons.osgi.symbolicName>org.apache.commons.lang.builder;version=${project.version}, org.apache.commons.lang.enum;version=${project.version}, org.apache.commons.lang.enums;version=${project.version}, org.apache.commons.lang.exception;version=${project.version}, orgcommons.componentid}</commons.osgi.symbolicName> <commons.osgi.export>org.apache.commons.lang.math*;version=${projectpom.version}, org.apache.</commons.lang.mutable;version=${project.version}, org.apache.commons.lang.text;version=${project.version}, org.apache.commons.lang.time;version=${project.version} osgi.export> </Export-Package><commons.osgi.import>*</commons.osgi.import> <commons.osgi.dynamicImport></commons.osgi.dynamicImport> <Import-Package> org.apache.commons.lang;version=${project.version}, org.apache.commons.lang.builder;version=${project.version}, org.apache.commons.lang.enum;version=${project.version}, org.apache.commons.lang.enums;version=${project.version}, org.apache.commons.lang.exception;version=${project.version}, org.apache.commons.lang.math;version=${project.version}, org.apache.commons.lang.mutable;version=${project.version}, org.apache.commons.lang.text;version=${project.version}, org.apache.commons.lang.time;version=${project.version} </Import-Package> </manifestEntries> </archive> </configuration> </plugin> |
*Notes:_'
...
<commons.osgi.private></commons.osgi.private>
</properties>
|
For example, depending on the nature/structure of the project, some packages might contain private classes that are not meant to be used by client code. In these cases, <Export-Package> should list all public packages while <Private-Package> should contain the private packages. This can be achieved by overriding the <commons.osgi.export>
and <commons.osgi.private>
properties in the component pom.
Version 8 of commons-parent required specifying <packaging>bundle</packaging>
in the component pom - with version 9 this is no longer required. In version 9, the maven-bundle-plugin
is configured to generate a MANIFEST.MF
file containing the OSGi meta data in the target/osgi
folder. The maven-jar-plugin
is configured to merge this generated MANIFEST.MF
file with the manifest entries it is configured with. If a component does not want to include OSGi meta-data in their pom's manifest file they can configure an alternative or blank manifest file location using the <commons.manifestfile>
property
...
.