How to use JACOB in an OSGi application?

Question

I have an OSGI (more precsiely a Wisdom framework-based) application in which i would like to use the JACOB library to interact with Office (the goal being to transform PPT into images). I can easily add the JACOB jar to my CLASSPATH, but JACOB requires the dll to be available in the java.library.path environment variable.

Question: How can I add it in my maven build?

EDIT I'm using maven 3

Answer 1

It appears JACOB has some special code which seems directly related to this class of errors. Indeed, there is a jacob.dll.path defined in LibraryLoader by which one can give Jacob an absolute path to access the jacob dll (which do not directly uses System.loadLibrary). Setting that library directly solved my problem.

Answer 2

You probably have three possibilities for this use case

MAVEN_OPTS

You could use the MAVEN_OPTS environment variable to pass to the Maven build the required JVM option (for the whole build, hence applying to all involved plugin/goal executions):

export MAVEN_OPTS="-Djava.library.path=<path_to_dir>"

However, this will be also applied to all other builds concerned by the same environment. In a Jenkins job you can still configure this variable per job, hence isolated within a certain build.

.mvn settings

Since Maven 3.3.1, you could have an .mvn folder as part of the concerned project and a jvm.config file as perfect place for such an option.

two new optional configuration files .mvn/jvm.config and .mvn/maven.config, located at the base directory of project source tree. If present, these files will provide default jvm and maven options. Because these files are part of the project source tree, they will be present in all project checkouts and will be automatically used every time the project is build.

As part of the official release notes

In Maven it is not simple to define JVM configuration on a per project base. The existing mechanism based on an environment variable MAVEN_OPTS and the usage of ${user.home}/.mavenrc is an other option with the drawback of not being part of the project.

Starting with this release you can define JVM configuration via ${maven.projectBasedir}/.mvn/jvm.config file which means you can define the options for your build on a per project base. This file will become part of your project and will be checked in along with your project. So no need anymore for MAVEN_OPTS, .mavenrc files. So for example if you put the following JVM options into the ${maven.projectBasedir}/.mvn/jvm.config file:

-Xmx2048m -Xms1024m -XX:MaxPermSize=512m -Djava.awt.headless=true

The options will be applied to all modules in case of a multi-module project.

Your ${maven.projectBasedir}/.mvn/jvm.config file could hence provide the following:

-Djava.library.path=<path_to_dir>

The main advantage of this approach is that the configuration is isolated to the concerned project and applied to the whole build as well.

Plugin configurations

You should set it to the concerned plugins and configuration entry, if any. For instance, the Maven Compiler Plugin provides the compilerArgs configuration entry for JVM options, the Maven Surefire Plugin provides the argLine configuration option for the same, and so on.

This is the least recommended approach since configuration would be duplicated and often not even possible (up to the plugin configurability). However, if the use case is really isolated to a certain plugin execution (compilation, testing, etc.), then it might still be reasonable.

Answer 3

I am a bit confused about the maven part since this is normally not a part of the runtime library when you use OSGi.

In OSGi, if you use the dll in your OSGi framework then this all can be setup by the OSGi framework. You must package the DLL into the JAR and provide some properties. In runtime, the framework then extracts the library and makes sure it can be found. (There is a bit of an issue with multiple DLLs that depend on each other.)

Here is some practical information about native libraries in OSGi:

http://enroute.osgi.org/appnotes/native-libraries.html