Planning Plugin Upgrades and Optimizations

If you’ve explored Liferay Portal CE 7.0’s features and possibly created new portlet modules themes with Liferay’s new tooling and techniques, you may be wondering how you’d upgrade existing plugins. The great thing is that Liferay has automated much of the upgrade process. In addition, you can continue developing plugins in traditional ways and adopt new development tooling and techniques when you’re ready.

This tutorial guides you through phases of upgrading plugins and optionally optimizing them.

Upgrade: A process for deploying an existing plugin on Liferay Portal CE 7.0 with minimal changes.

Optimization: An optional but recommended process for modifying a plugin or migrating it to a new environment to improve the plugin or facilitate developing it.

Importantly, you should upgrade a plugin before applying any optimizations to it.

The good news is that upgrading plugins to Liferay Portal CE 7.0 is straightforward. For Plugins SDK and Maven projects, Liferay IDE’s Code Upgrade Tool automates much of the process. In addition, the upgrade tutorials demonstrate any remaining upgrade steps.

You can deploy plugins to Liferay Portal CE 7.0 as you have for previous releases (e.g., ant clean deploy). Since everything in Liferay Portal CE 7.0 runs as OSGi modules, however, you might wonder how traditional WAR-style plugins can run on it. The answer: Liferay’s Plugin Compatibility Layer.

The Plugin Compatibility Layer converts standard WARs to Web Application Bundles (WABs). WABs are full-fledged OSGi modules. The Plugin Compatibility Layer’s WAB Generator supports deploying traditional plugins and web applications that contain Servlets, JSPs, and other Java web technologies without making any OSGi specific changes to them.

Note, you can still use an application server’s mechanisms to deploy regular web applications along with Liferay Portal, without using the Plugin Compatibility Layer.

After upgrading your plugins you can consider optimizations such as these:

See the optimization tutorials for more options and details.

You can continue using the Plugins SDK to develop plugins. But the Plugins SDK is deprecated as of Liferay Portal CE 7.0. In light of the deprecation, you should consider migrating plugins from the Plugins SDK to one of the new environments:

  • Liferay Workspace is a Gradle environment that supports developing modules and traditional plugins. Blade’s migrateWar command moves Plugins SDK portlets to Liferay Workspace (Workspace) in a snap.
  • Liferay’s Maven plugins and archetypes support developing modules and traditional plugins. There’s also a Liferay Workspace archetype for generating a Workspace that uses Maven.

Liferay IDE supports developing in Workspaces using Gradle or Maven.

In short, there’s plenty of time to move plugins out of the Plugins SDK, but you should at least plan for migrating to a new environment that works best for you.

Speaking of planning, properly planned upgrades and optimizations reduce the time and effort they take. To help guide you through the upgrade and optimization tutorials, you get these things:

  • Upgrade and optimization phase descriptions
  • Upgrade and optimization paths

Upgrade and Optimization Phases

Follow these upgrade and optimization phases:

  1. Read the applicable upgrade tutorials for your plugin. Examine the upgrade and optimization paths.

  2. Upgrade the plugin, making only the minimal changes necessary for it to work on Liferay Portal CE 7.0.

  3. (Optional) Identify and apply only the most beneficial optimizations for your plugin.

  4. (Optional) Apply additional optimizations as desired.

Upgrade and Optimization Paths

The following tables provide upgrade and optimization paths for 6.2 plugins and features.

Plugin Upgrade and Optimization Paths

Plugin Upgrade path Optimizations (optional)
Ext Customization with Ext Plugins None
Hook - Language files - Upgrading Core Language Key Hooks
- Upgrading Portlet Language Key Hooks
Hook - Override a Liferay Portal Core JSP Upgrading Core JSP Hooks Same
Hook - Override an app’s JSP Upgrading App JSP Hooks Same
Hook - Event Actions (Portal/Session/Servlet Service/Shutdown/Startup) Upgrading Portal Property and Event Action Hooks Coming soon
Hook - Model Listeners Upgrading Model Listener Hooks Same
Hook - Portal Properties Upgrading Portal Property and Event Action Hooks Same
Hook - Properties - If the property is now a System Setting, edit it there and/or use a .config file
- If the property is in the liferay-hook.xml’s DTD, then adapt code to API and resolve dependencies
Hook - Service Wrappers Upgrading Service Wrappers Coming soon
Hook - Servlet Filter Upgrading Servlet Filter Hooks Coming soon
Hook - Struts actions - StrutsAction → StrutsActionWrapper
- processAction → MVCActionCommand
- render → MVCRenderCommand
- serveResource → MVCResourceCommand
Layout Template 1. Adapt code to API
2. Resolve dependencies
3. Update Layout Template
- Migrate to Liferay Theme Generator (Node.js/Gulp/Yeoman)
Portlet - GenericPortlet Upgrading a GenericPortlet - Migrate to Workspace/Gradle
- Apply Lexicon
- Convert to OSGi modules
Portlet - Liferay MVC Upgrading a Liferay MVC Portlet - Migrate to Workspace/Gradle
- Apply Lexicon
- Convert to OSGi modules
Portlet - JSF Upgrading a Liferay JSF Portlet None
Portlet - Servlet/JSP Upgrading a Servlet-based Portlet Coming soon
Portlet - Spring MVC Upgrading a Spring MVC Portlet None
Portlet - Struts 1 Upgrading a Struts Portlet None
Theme 1. Adapt code to API
2. Resolve dependencies
3. Upgrade Theme
- Migrate to Liferay Theme Generator (Node.js/Gulp/Yeoman)
- Use Themelets
Web plugin 1. Adapt code to API
2. Resolve dependencies
Convert to OSGi module, e.g., portlet-x-web

Feature Upgrade and Optimization Paths

Feature Upgrade path Optimizations (optional)
JNDI data source Use Liferay Portal’s classloader to access the app server’s JNDI API None
Resources Importer Update the Resources Importer None
Services - Invoke a service from Liferay Portal Core or another portlet or module Implement a Service Tracker Invoke Liferay services from a module
Services - Module dependency Copy x-service.jar to WEB-INF/lib - Migrate to Gradle/Maven and add dependency on the OSGi service
Services - Service Builder Upgrading Portlets that use Service Builder Convert to OSGi modules, e.g., x-api and x-service
Services - Web services 1. Adapt code to API
2. Resolve dependencies
Use a Service Builder service with JAX-RS with a REST service in front
Template - FreeMarker - Adapt code to API
- Adapt Theme templates
Template - Velocity (deprecated) Adapt code to API Convert to FreeMarker

Now you have a game plan and a cheat sheet for upgrading and optimizing plugins with confidence.

0 (0 Votes)
Improved Developer Tooling: Liferay Workspace, Maven Plugins and More Previous