A Liferay Workspace is a generated environment that is built to hold and manage your Liferay projects. This workspace is intended to aid in the management of Liferay projects by providing various build scripts and configured properties. You can download the Liferay Project SDK installer and run it to install Blade CLI (default CLI for workspace), initialize a new Liferay Workspace, and download Dev Studio DXP.
Liferay Workspace is the official way to create/manage Liferay DXP 7.2 projects using Gradle. Do you prefer Maven over Gradle? You can also generate a Maven-based workspace.
You’ll cover the following topics in this section:
- Installing Liferay Workspace
- Creating a Liferay Workspace
- Importing a Liferay Workspace
- Setting Proxy Requirements
- Adding a Bundle
- Setting Environment Configurations
- Building Node.js Themes
- Building Gradle/Maven Themes
- Managing the Target Platform
- Validating Modules Against the Target Platform
- Leveraging Docker
- Updating Liferay Workspace
- Updating Default Plugins Provided by Liferay Workspace
Liferay Workspaces can be used in many different development environments, which makes it flexible and applicable to many different developers. For example, a Liferay Workspace easily integrates with Eclipse and IntelliJ, providing a seamless development experience. See how to install and create a Liferay Workspace for more information.
You’ll learn about workspace’s anatomy and development lifecycle next.
A Liferay Workspace offers a development environment that can be configured to fit your development needs. Properties are available to help manage default and optional folders. This provides you the power to customize your workspace’s folder structure any way you’d like. The top-level files/folder of a Liferay (Gradle) Workspace are outlined below:
bundles(generated): the default folder for Liferay DXP bundles.
configs: holds the configuration files for different environments. These files serve as your global configuration files for all Liferay DXP servers and projects residing in your workspace. To learn more about using the
configsfolder, see the Testing Projects section.
ext(generated): holds the Ext OSGi modules and Ext plugins.
gradle: holds the Gradle Wrapper used by your workspace.
modules: holds your custom modules. This can also hold front-end portlets created with the Liferay JS Toolkit.
themes: holds Node.js-style themes that use the Liferay JS Theme Toolkit, which are built using the Liferay Theme Generator.
wars: holds traditional WAR-style web application projects and theme projects (i.e., generated by the
build.gradle: the common Gradle build file.
gradle.properties: specifies the workspace’s project locations and Liferay DXP server configuration globally.
gradle-local.properties: sets user-specific properties for your workspace. This lets multiple users use a single workspace, letting them configure specific properties for the workspace on their own machine.
gradlew: executes the Gradle command wrapper.
settings.gradle: applies plugins to the workspace and configures its dependencies.
If you’re using a workspace generated for Maven projects, your folder hierarchy
is the same, except the Gradle build files are swapped out for a
Visit your workspace’s
gradle.properties file for a list of properties (with
descriptions) you can define to adapt your workspace. For a Maven-based
workspace, see the
Bundle Support Plugin
article for info on adapting your Maven workspace.
If you’d like to keep the global Gradle properties the same, but want to change
them for yourself only (perhaps for local testing), you can override the
gradle.properties file with your own
Next, you’ll learn about workspace’s development lifecycle.
Liferay Workspaces offer a full development lifecycle for your projects to make your Liferay development easier than ever. The development lifecycle includes
You’ll learn about each lifecycle option next.
Workspace provides a slew of
that you can use to create many different types of Liferay projects. Workspace
also provides development support for front-end portlets generated with the
Liferay JS Toolkit.
They’re stored in the
modules folder by default.
You can also configure where to generate certain projects (modules, themes,
WARs, etc.). These settings are documented in the
gradle.properties file. See
Creating a Project
article for more information.
Liferay Workspace manages theme projects in two separate folders based on how they’re created:
- Liferay Theme Generator (Node.js-based themes that use the Liferay JS Theme Toolkit)
- Project template/archetype (Gradle/Maven-based themes)
Liferay Workspace offers an environment where developers can use the Liferay Theme Generator to create themes and their work can be seamlessly integrated into their overall DevOps strategy. You can leverage the Liferay Theme Generator to create Node.js-based themes inside workspace or you can leverage it externally and copy themes into Workspace.
Workspace also offers a traditional Java-based theme approach (leveraging Gradle/Maven) for those that can’t use the Liferay JS Theme Toolkit’s tools in their CI environment.
Liferay Workspace abstracts many build requirements away so you can focus on developing projects instead of worrying about how to build them. This is done by incorporating a slew of plugins under the hood to allow for easily accessible tooling. See the Gradle Plugins and Maven Plugins sections for information on some of the plugins provided by workspace.
Gradle-based workspaces also include a Gradle wrapper in its ROOT folder (e.g.,
gradlew), which you can leverage to execute Gradle commands. This means that
you can run familiar Gradle build commands (e.g.,
etc.) from a Liferay Workspace without having Gradle installed on your machine.
For Maven-based workspaces, Maven build commands are supported (e.g.,
Liferay Workspace lets you build your projects out-of-the-box without the hassle of manual build configurations.
Liferay Workspace provides easy-to-use deployment mechanisms that let you deploy your project to a Liferay server without any custom configuration. To learn more about deploying projects from a workspace, visit the Deploying a Project article.
Liferay provides many configuration settings for Liferay DXP 7.2. Configuring several different Liferay DXP installations to simulate/test certain behaviors can become cumbersome and time consuming. With Liferay Workspace, you can easily organize environment settings and generate an environment installation with those settings.
Liferay Workspace provides the
configs folder, which lets you configure
different environments in the same workspace. For example, you could configure
separate Liferay DXP environment settings for development, testing, and production
in a single Liferay Workspace. So how does it work?
configs folder offers six subfolders:
common: holds a common configuration that you want applied to all
dev: holds the development configuration.
docker: holds the configuration for a Docker container.
local: holds the configuration intended for testing locally.
prod: holds the configuration for a production site.
uat: holds the configuration for a UAT site.
You’re not limited to just these environments. You can create any subfolder in
configs folder (e.g.,
test, etc.) to simulate any environment.
Each environment folder can supply its own database,
Elasticsearch, etc. The files in each folder overlay your Liferay DXP
installation, which you generate from within workspace.
When workspace generates a Liferay DXP bundle, these things happen:
Configuration files found in the
configs/commonfolder are applied to the Liferay DXP bundle.
The configured workspace environment (
local, etc.) is applied on top of any existing configurations from the
See the Setting Environment Configurations for Liferay Workspace article for more information.
Liferay Workspace does not provide a built-in release mechanism, but there are easy ways to use external release tools with workspace. The most popular choice is uploading your projects to a Maven Nexus repository. You could also use other release tools like Artifactory.
Uploading projects to a remote repository is useful if you need to share them with other non-workspace projects. Also, if you’re ready for your projects to be in the spotlight, uploading them to a public remote repository gives other developers the chance to use them.