Best Practice: Update Your Buildchain

When you "blade init" a new project, you shouldn't consider the project frozen.

So just a quick post here about your Liferay build chain...

It is easy, when you're starting out, to follow the instructions to install the Blade CLI or the Maven artifacts.

It is also easy, even after you've been developing for awhile, to "blade init" a new project or "mvn archetype:generate" a new project and write your next great software masterpiece.

And while you may know that Liferay supplies newer GAs of the community edition of Liferay and new Fix Packs and Service Packs for Liferay DXP, you might not be aware that Liferay is also constantly improving the build tools.

I'm not talking just about major build releases or releases about updated Maven or Gradle tools. I'm talking about regular bugfixes that get applied to all of the plugins that you are using (whether you're aware of it or not). After all, Liferay eats its own dogfood in this area, so they are frequently finding and fixing issues in the plugins; you too should update in order to take advantage of these fixes.

The Liferay Gradle Workspace is itself significantly based on Liferay's Gradle plugins; the workspace plugin is listed in the settings.gradle file, but internally it yanks in all of the other relevant Liferay Gradle plugins that handle theme building, war building, target platform, service builder, etc. So selecting a workspace plugin version implies selecting versions of these other plugins too.

On the Maven side, it's easy not to go back to the POM and update for newer plugin versions, especially since there isn't really a big announcement corresponding the new plugin version availability, but that doesn't mean you shouldn't do it from time to time.

So here's a Liferay Development Best Practice:

Update Your Buildchain

Seriously, get in those build.gradle files and pom.xmls and make sure you're using the latest versions of your build tools. Maven and Gradle are not going to do this for you, this is something you have to do yourself.

And yes, from time to time if you ride the bleeding edge you are going to get cut. If you are concerned about that, then hang back a minor version or two, updating to the latest after it has had some time to get fully baked.

How can you find out what versions of the build plugins are available?

I'm so glad you asked. Fortunately, Maven and Gradle pull their plugins from the same repositories where they pull dependencies. Unfortunately, the plugins can get mixed in with dependencies, so you might need a bit to track them down.

The Service Builder plugin for Gradle, for example, has the group "com.liferay" and the name "com.liferay.gradle.plugins.service.builder". We can go to the Liferay repository at to check all of the available versions and we see the list runs from the first 1.0.0 snapshot through the current 2.2.42. That's a huge range difference if you're still back in the early 1.x versions.

Some words of caution that you should keep in mind...

First, with Gradle plugins the versions can be tied to Gradle versions. Like, I don't know this for sure, but the 1.x versions of the ServiceBuilder plugins could be for Gradle 3 and the 2.x versions for Gradle 4. I don't know this is the case, but I guess it could happen.

Also, the versions could be tied to Liferay version. After all, there were some internal changes for SB between Liferay 7.0 and 7.1, and I'm sure that the plugin changes would have reflected that somehow, but I'm not sure if the version numbers imply that or not.

While I'm trying to track down those details, let me just suggest that you should test before committing the change. You really want to know that the SB 2.2.42 plugin builds SB code that works in your version of Liferay using your version of Gradle before you commit the change. Maybe for your environment you need to stick with the 1.x versions of the plugin, but that still means you could be going from the early 1.0.0 versions up to a later 1.0.65...