Liferay Workspaces provide an environment that supports all phases of a Liferay module’s development lifecycle:
In this tutorial, you’ll explore the development lifecycle phases Liferay Workspace provides for you. Then you’ll be directed to other tutorials that go into further detail for leveraging the workspace’s particular lifecycle phase for a specific tool (e.g., Blade CLI or Liferay IDE). Let’s get started!
The first step of Liferay Workspace’s development phase is the module creation process. Workspace provides a slew of templates that you can use to create many different types of Liferay modules.
You can configure where your workspace creates modules by editing the
liferay.workspace.modules.dir property in the workspace’s
gradle.properties file. By default, modules are created in the
You can also control where themes are generated by specifying the
liferay.workspace.themes.dir property in the
gradle.properties file. Themes are typically migrated to the
themes folder after being created using the Liferay Theme Generator.
Liferay Workspace abstracts many build requirements away so you can focus on developing modules instead of worrying about how to build them. Liferay Workspace is built using Gradle, so your modules leverage the Gradle build lifecycle.
Workspace includes 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.,
compile, etc.) from a Liferay Workspace without having Gradle installed on your machine.
When using Liferay Workspace, the workspace plugin is automatically applied which adds a multitude of subprojects for you, hiding some complexities of Gradle. For example, a typical project’s
settings.gradle file could contain many included subprojects like this:
... include images:base:oracle-jdk:oracle-jdk-6 include images:base:oracle-jdk:oracle-jdk-7 include images:base:oracle-jdk:oracle-jdk-8 include images:base:liferay-portal:liferay-portal-ce-tomcat-7.0-ga1 include images:source-bundles:glassfish include images:source-bundles:jboss-eap include images:source-bundles:tomcat include images:source-bundles:websphere include images:source-bundles:wildfly include compose:jboss-eap-mysql include compose:tomcat-mariadb include compose:tomcat-mysql include compose:tomcat-mysql-elastic include compose:tomcat-postgres include file-server ...
You don’t have to worry about applying these subprojects because the workspace plugin does it for you. Likewise, if a folder in the
/themes folder includes a
liferay-theme.json file, the
gulp plugin is applied to it; if a folder in the
/modules folder includes a
bnd.bnd file, the liferay-gradle plugin is applied to it. See the Gradle reference article for a list of Liferay Gradle plugins automatically provided for all Workspace apps. As you can see, Liferay Workspace provides many plugins and build configurations behind the scenes to make your development process convenient.
A good example of the Gradle build lifecycle abstraction is the module deployment process in a workspace. You can build/deploy your modules from workspace without ever running a Gradle command. You’ll learn how to do this next.
Liferay Workspace provides easy-to-use deployment mechanisms that let you deploy your module to a Liferay server without any custom configuration. To learn more about deploying modules from a workspace using Blade CLI or Liferay IDE, visit the Deploying Modules with Blade CLI and Deploying Modules with Liferay IDE tutorials, respectively.
Liferay provides many configuration settings for Liferay Portal CE 7.0. Configuring several different Liferay Portal 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 Portal environment settings for development, testing, and production in a single Liferay Workspace. So how does it work?
configs folder offers five subfolders:
common: holds a common configuration that you want applied to all environments.
dev: holds the development configuration.
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 the
configs folder (e.g.,
docker, etc.) to simulate any environment. Each environment folder can supply its own database,
portal-ext.properties, Elasticsearch, etc. The files in each folder overlay your Liferay Portal installation, which you generate from within workspace.
When workspace generates a Liferay Portal bundle, these things happen:
Configuration files found in the
configs/commonfolder are applied to the Liferay Portal bundle.
The configured workspace environment (
uat, etc.) is applied on top of any existing configurations from the
To generate a Liferay Portal bundle with a specific environment configuration to the workspace’s
/bundles folder, run
./gradlew initBundle -Pliferay.workspace.environment=[ENVIRONMENT] <!-- `blade server init` is not able to pass the environment param in currently. This new feature is requested in BLADE-343. -Cody -->
To generate a distributable Liferay Portal installation to the workspace’s
/build folder, run
./gradlew distBundle[Zip|Tar] -Pliferay.workspace.environment=[ENVIRONMENT]
ENVIRONMENT variable should match the configuration folder (
uat, etc.) you intend to apply.
To simulate using the
configs folder, let’s explore a typical scenario. Suppose you want a local Liferay Portal installation for testing and a UAT installation for simulating a production site. Assume you want the following configuration for the two environments:
- Use MySQL database pointing to localhost
- Skip setup wizard
- Use MySQL database pointing to a live server
- Skip setup wizard
To configure these two environments in your workspace, follow the steps below:
- Open the
configs/commonfolder and add the
portal-setup-wizard.propertiesfile with the
- Open the
configs/localfolder and configure the MySQL database settings for localhost in a
- Open the
configs/uatfolder and configure the MySQL database settings for the live server in a
Now that your two environments are configured, generate one of them:
./gradlew distBundle[Zip|Tar] -Pliferay.workspace.environment=uat
You’ve successfully configured two environments and generated one of them.
Awesome! You can now test various Liferay Portal bundle environments using Liferay Workspace.
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 modules to a Maven Nexus repository. You could also use other release tools like Artifactory.
Uploading modules to a remote repository is useful if you need to share them with other non-workspace projects. Also, if you’re ready for your modules to be in the spotlight, uploading them to a public remote repository gives other developers the chance to use them.