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.
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’slib
folder and adds the JARs to the module’sBundle-ClassPath
manifest header.NoteThe
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.
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.