Submit Feedback

Resolving Third Party Library Package Dependencies

An application can rely on multiple OSGi modules. Resolving their Java package dependencies can be challenging. In a perfect world, every package would be distributed in OSGi JARs, but many packages are only in traditional libraries (non-OSGi JARs). You can resolve dependencies on third party, non-OSGi JARs in several ways:

Projects, such as Eclipse Orbit and ServiceMix Bundles, convert hundreds of traditional Java libraries to OSGi modules. You might find an OSGi JAR with the packages.
- Eclipse Orbit downloads (select a build)
- ServiceMix Bundles
If you find a module with the packages, deploy it and add a compileOnly dependency on it. If there is no module for the packages, continue to the next step.
Check if Liferay already exports library packages you’re using. If Liferay exports them, adjust your dependency per the instructions in Exported Third Party Packages.
Add the non-OSGi JAR as a compileInclude dependency:
```
dependencies {
    compileInclude group: 'org.apache.shiro', name: 'shiro-core', version: '1.1.0'
}
```
Liferay’s compileInclude configuration is transitive—it embeds the library and all of its dependencies in the module JAR’s lib folder and adds the JARs to the module’s Bundle-ClassPath manifest header.

Note

The compileInclude configuration does not download transitive optional dependencies. If you require a package from an optional dependency, resolve the package as you would another third party library package.
Compile your module.
Deploy your module and check for unresolved package dependencies.
If there is an unresolved dependency on a package your module doesn’t use, block importing that package.
```
Import-Package:\
    !foo.bar.baz,\
    *
```
The !character negates importing the package. The * character represents all packages that the module refers to explicitly. Putting * at the end of the list causes Bnd to import all packages your module references.

Note

If your WAR file requires a different version of a third-party package that Liferay exports already, specify that package in your Import-Package: list. If that package is in an OSGi module, deploy it.

When Liferay DXP deploys a WAR, it converts it to a WAB, and it strips already exported third-party JARs out of WABs at deploy time. To force deployment of a different version than Liferay exports, rename that package’s non-OSGi JAR differently from the JAR that the WAB generator excludes and embed the JAR in your project.

Congratulations! You resolved dependencies on packages from non-OSGi JARs.

Capability: