36.5. Deploy to an OSGi Container
- Bundles are a relatively lightweight deployment option (because dependencies can be shared between deployed bundles).
- OSGi provides sophisticated dependency management, ensuring that only version-consistent dependencies are added to the bundle's classpath.
Using the Maven bundle plug-in
- Change the packaging type to
bundle(by editing the value of the
project/packagingelement in the POM).
- Add the Maven bundle plug-in to your POM file and configure it as appropriate.
Sample bundle plug-in configuration
<?xml version="1.0"?> <project ...> ... <groupId>com.fusesource.byexample.cxf-webinars</groupId> <artifactId>customer-ws-client</artifactId> <name>customer-ws-client</name> <packaging>bundle</packaging> ... <build> <plugins> ... <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <extensions>true</extensions> <configuration> <instructions> <Export-Package> !com.fusesource.customer.client, !com.fusesource.demo.customer, !com.fusesource.demo.wsdl.customerservice </Export-Package> <Import-Package> * </Import-Package> <DynamicImport-Package> org.apache.cxf.*, org.springframework.beans.* </DynamicImport-Package> </instructions> </configuration> </plugin> ... </plugins> </build> </project>
DynamicImport-Packageelement). This is a pragmatic way of dealing with the fact that Spring XML files are not terribly well integrated with the Maven bundle plug-in. At build time, the Maven bundle plug-in is not able to figure out which Java classes are required by the Spring XML code. By listing wildcarded package names in the
DynamicImport-Packageelement, however, you allow the OSGi container to figure out which Java classes are needed by the Spring XML code at run time.
DynamicImport-Packageheaders is not recommended in OSGi, because it short-circuits OSGi version checking. Normally, what should happen is that the Maven bundle plug-in lists the Java packages used at build time, along with their versions, in the
Import-Packageheader. At deploy time, the OSGi container then checks that the available Java packages are compatible with the build time versions listed in the
Import-Packageheader. With dynamic imports, this version checking cannot be performed.
Build and deploy the client bundle
karaf@root> install -s mvn:com.fusesource.byexample.cxf-webinars/customer-ws-client
org.ops4j.pax.url.mvn.localRepositoryproperty in the
EsbInstallDir/etc/org.ops4j.pax.url.mvn.cfgfile, before you can use the
mvn:scheme to access Maven artifacts.
Check that the client is running
karaf@root> log:display -n 10