Make Third Party non OSGi JAR as Liferay Portal Global Library

Liferay 7.2/DXP Portal environment is leveraging OSGi modularity framework.  Sometimes we may need java libraries which is required for all Liferay OSGi modules and these are common JARs to every module. Instead of adding these jars to every module and we can make it global jar.

If any use case which meets the following criteria then we can make specific non-OSGi jar as Global.

• Any third party or project specific custom jars are non-OSGi libraries
• JARs are common libraries and required for all Liferay OSGi modules.

Liferay 7.2/DXP Portal already made many of common libraries as global and these jars are available in portal server tomcat/lib/ext directory.

Example

The following are check list before you make any third-party jar as global library.

Verify that Liferay OSGi module required jar already part of portal global library(lib/ext).

Verify that module required specific package in the list of portal property “module.framework.system.packages.extra”

Verify that module required specific package in the list of Portal Exported System package list of com.liferay.portal.bootstrap.jar “system.packages.extra.mf”.

Liferay Module Framework already exported many of common libraries as part of portal bootstrap module and these are available to all Liferay OSGi modules.

If the package or jar already not available as global then the following are the steps to add third party non-OSGi jar as global library.

1. Add required jar in the Portal Tomcat lib/ext directory
2. Override “module.framework.system.packages.extra” portal property and add required packages in list.
3. Restart Portal Server

Add required jar in the Portal Tomcat “lib/ext” directory

Download or get required jar libraries and add in the portal tomcat lib/ext.

Take the example Liferay OSGi modules required some JSON libraries and wanted to use google gson library. Download required version of JAR from internet and place it in Tomcat lib/ext.

Override “module.framework.system.packages.extra” portal property and add required packages in list.

Now add jar base package or required packages in the list of “module.framework.system.packages.extra” portal property.

Use “portal-ext.properties” file to override portal properties and it should be available in Liferay home directory.

Example portal property in portal-ext.properties

module.framework.system.packages.extra=\         com.ibm.crypto.provider,\         com.ibm.db2.jcc,\        com.google.gson,\         com.microsoft.sqlserver.jdbc,\         com.mysql.cj.jdbc,\         com.mysql.jdbc,\         com.p6spy.engine.spy,\         com.sun.security.auth.module,\         com.sybase.jdbc4.jdbc,\         oracle.jdbc,\         org.postgresql,\         org.hsqldb.jdbc,\         org.mariadb.jdbc,\         sun.misc,\         sun.net.util,\         sun.security.provider,\         \         #         # WebSocket Support         #         \         com.ibm.websphere.wsoc,\         io.undertow.websockets.jsr,\         javax.websocket,\         javax.websocket.server,\         org.apache.tomcat.websocket.server,\         org.eclipse.jetty.websocket.server,\         org.glassfish.tyrus.servlet,\         weblogic.websocket.tyrus

Restart Portal Server

Finally restart portal server and now use gson packages anywhere in the Liferay OSGi modules.

Usage in the Liferay OSGi modules

Maven Liferay OSGi module

Add gson dependency in module pom.xml file with provided scope.

Example:

<dependency>    <groupId>com.google.code.gson</groupId>    <artifactId>gson</artifactId>    <version>1.1</version>    <scope>provided</scope> </dependency>

Gradle Liferay OSGi module

Add dependency in module “build.gradle” compileOnly group

dependencies {                compileOnly group: "com.google.code.gson", name: "gson", version: "1.1"             }

Note:

I just took old gson jar to demonstrate the process of making non-OSGi jars as global. The latest gson jars are OSGi compliance and we can simply deploy into Liferay Module Framework.

Important Points

If we really required or demanded then only, we should make non-OSGi jars as global. We have to avoid this as much possible.

When we make any non-OSGi jars as global then we should also make its transitive dependencies as global.

We cannot make use of multiple versions of implementations to consumer modules and we have to stick with only the version that we added as global.

Author

Meera Prince

Liferay Contributor of the Year 2016
Liferay Top Contributor Award Winner 2015

Liferay Contributor of the Year 2014

Liferay Top Contributor Award Winner 2013

http://www.liferaysavvy.com