The thought of – Module vs Plugin was introduced from Liferay 7 which is built on top of modular framework called OSGI. So it is crucial to understand this concept.
Starting with version 7, Liferay leverages the OSGi platform for doing modular application development. In all previous Liferay releases (till 6.2), the single unit of development was called plugin (or Liferay Plugin) like portlet, hook, layout, theme, and EXT.
Since Liferay 7 is moved towards the modular framework, the single unit of development is called a module. In short, a module can be described as the Liferay 7 plugin, which contains a group of classes with a MANIFEST file along with additional resources, packaged into a JAR file.
One fact (and probably the difference) between module and plugin is, multiple modules can form an application in Liferay 7. If you could see, many out of the box applications (for example, web content display portlet in Liferay 7) are divided into multiple modules like API, Service, and Web modules.
This is not possible in the plugin case because a single plugin (as a traditional J2EE web application) represents the whole application.
As a Liferay developer, It is essential to understand the difference between the module vs. plugin. There are various perspectives from which you can understand the differences. Let’s look at all of them.
Release, Framework, and Run-time
Module: As we know, Liferay 7 provides development on top of the OSGi platform for a modular system. So modules/bundles came into the picture, starting with Liferay 7 (DXP). OSGi framework is used to develop modules. OSGi container is required to execute modules.
Plugin: Support for the plugin was there from the initial releases of the Liferay. Plugins were developed with the traditional J2EE web application framework. The application server or servlet container (like Tomcat) provides a runtime environment for plugins.
Packaging of module vs. plugin
Module: As an OSGI standard, modules are packaged as JARs.
Plugin: Since plugin runs as a web application, they are packaged in the form of WARs
Plug & Play with module vs plugin
Module: Modules are, in a true sense, Plug & Play. Once they are deployed, you can simply active, in-active, start, stop with a single command without completely un-deploying it. Further, any out of the box application (which is in the form of multiple modules) can be on and off without restarting the Liferay server.
Plugin: Though custom developed plugins are kind of Plug and Play, you need to completely un-deploy if you want to remove it. There are no such things as Active or Inactive; it is deployed or undeployed. Additionally, you can’t make on and off any out of the box applications because Liferay (of all prior version than 7) is deployed as a whole single application.
Lifecycle management of module vs plugin
Module: Liferay 7 provides the Command Line Tool (CLI) called Apache GOGO shell to manage the module’s lifecycle. For example, you can active, inactive, start, stop, install, uninstall the modules with GOGO Shell commands. It is an OSGI container that manages the lifecycle of modules.
Plugin: On the other hand, there is no such thing available for the plugin. The plugin can either deployed or undeployed manually by deleting the folder on the server. Some application servers provide support to deploy / un-deploy plugin from the server console.
The application server is responsible for handling the lifecycle management of the plugin.
Deployment of module vs plugin
Module: Module JARs are deployed into osgi/module folder as it is.
Plugin: Whereas plugins are deployed under the application server-specific deployment folder. For example, in the case of tomcat, plugins are deployed under the webapps folder. Since they are in the form of WAR, they are deployed in extracted form.
Deployment descriptor of module vs plugin
Module: Since modules are in the form of JARs, they have a deployment descriptor in the form of a META-INF file, which contains deployment information used by the OSGi container.
Plugin: Plugins are in the form of standard J2EE web application format. So just like any other J2EE web application, they have web.xml as a deployment descriptor.
Configuration of module vs plugin
Module: With Declarative Services (DS), Liferay 7 provides a way to define all configurations as component properties. So you won’t find any XML file for Liferay 7 Modules. For example, portlet.xml, liferay-portlet.xml, etc., will not be part of modules. You can set respective properties in the component (java) class directly.
Plugin: On the contrary, plugins support XML files for defining various configurations. (portlet.xml, liferay-portlet.xml).
Build Tools used for module vs plugin
Module: Liferay 7 supports building modules with Gradle (by default), Maven, or Ant / Ivy.
Plugin: On the other hand, Plugins can be built with Maven or Ant / Ivy.
Workspace for module vs plugin
Module: Liferay 7 introduced workspace concepts (This is more or less like an eclipse workspace). All your modules and configuration would be part of the Liferay workspace. Only one workspace per project is allowed. This concept is by default ( and recommended by Liferay).
Because of the Liferay workspace, it is easy to move the code between various environments than the traditional development environment.
Plugin: In the case of the Liferay Plugin, any standard eclipse workspace can be used. Liferay provides Plugin SDK to develop various plugins. However, in the case of Maven, even plugin SDK is not required.
Development Frameworks for module vs plugin
Module: Since modules are specific to OSGI, there are certain limitations in choosing the framework to build them. For example, OSGi doesn’t support Spring, you can’t use the Spring framework to develop the OSGI module.
Instead, you have to follow old architecture (WAR), which Liferay 7 still supports as backward compatibility.
Plugin: On the other side, there is no such restriction in the case of a plugin. You can use various frameworks like Spring, JSF, Struts frameworks to build plugins.
Microservice architecture with module vs plugin
Module: OSGI platform is meant for developing a loosely coupled system. The whole application is divided into modules that work separately, focusing only on specific areas of function. Even further, a single module can be span across multiple components for further modularity.
In short, the OSGi platform provides a microservice-based architecture to execute Liferay modules independently out of the box.
Plugin: Plugins on the different side has no such things available out of the box. They are in the form of a single web application. You need to rely on other frameworks to produce microservice capabilities with your own.
You can learn and understand the concepts of modules from the below resources.
