Overview This guide walks through creating two OSGi modules in Liferay 7.4 and sharing a Java package between them using the standard API + Implementation pattern. This is the most common and correct approach for exposing reusable services in a Liferay-based architecture. In OSGi, a bundle (module) does not expose its internal packages by default — everything is private unless explicitly exported. To share code between modules, the standard practice is to split functionality into: · An API module — contains interfaces/DTOs and exports the package · A Service (Implementation) module — implements the interface, imports the package, and registers the implementation as an OSGi component/service The consuming module then simply imports the API package and looks up the service using @Reference injection. Step 1: Create the API Module Using Liferay Workspace + Blade CLI, generate a new API module: blade create -t api -p com.sgc.greeting greeting-api This generates a Gradle module unde...
Introduction to OSGi OSGi (Open Services Gateway initiative), now maintained as the OSGi Alliance's core module framework, is a dynamic module system for Java. It defines how independent units of code, called bundles, are packaged, deployed, versioned, started, stopped, and wired to one another at runtime — all without restarting the JVM. At its core, OSGi solves three problems that plain Java (and traditional WAR-based deployment) does not solve well: Modularity — code is packaged into bundles with explicit imports/exports, so internal implementation details stay hidden (encapsulation at the JAR level, not just the class level). Versioning — multiple versions of the same package or library can co-exist in the same JVM, each bundle wired to the version it actually needs. Dynamism — bundles can be installed, updated, started, and stopped individually, at runtime, without redeploying or restarting the whole application. 1.1 Key Building Blocks ...