Blogs

A search for a better SDK

A little over a year ago, the Dev Tools Team began a new project hoping to fix the issues we encountered with the Plugins SDK. We had just finished modularizing our developer tools and were considering revamping the Plugins SDK to use all the new tools. This in itself would be a major improvement since we would no longer require a 300mb bundle just to use it. We decided, however, that it was time for a change.

Our first commits for Liferay Workspace started early last year (January 7, 2016 to be exact) and we've made a huge amount of progress since then. Many of you may have already created projects in Workspace since it's been in the wild for a while now. If you haven’t tried it yet, you can create one by first installing Blade CLI and then running blade init <my-project>. You should experiment with it a bit before proceeding to get some context because I won't be covering every aspect, but instead, just our design decisions.

Why we built Workspace the way we did?

Liferay Workspace is an opinionated, yet highly configurable multi-level project structure. It’s a combination of the strengths we found in the Plugins SDK and also what I found in other build tools such as Maven, Ruby on Rails, Gradle, and feedback from our users.

Having structure is good. Forcing structure is bad.

The most polarizing complaint with the Plugins SDK we heard was about the structure. It was laid out with preconfigured folders of hooks, layouttpl, portlets, themes, webs, etc. Some people love this structure since it was clear where to place their projects, but others hated it.

When developing Workspace, we decided that the structure was good for folks new to Liferay, but could be limiting for those who knew it well. Workspace comes with the following folders: configs, modules, themes, and wars. It’s clear what should go in each folder. If you don't like it, however, you can rename them, have multiple versions of the same types, or delete them.

Upgrading your SDK needs to be easy

The Plugins SDK was completely configured in the XML files. Since everything Liferay did was through the build.xml files, and we didn't provide any way for you to make changes easily, it meant upgrading your SDK was a chore.

While the original design of Liferay Workspace was to do everything in the build.gradle files, we quickly realized that it made upgrading a problem again. We rewrote everything into a plugins; issue solved. The biggest benefit from this is now we’re rapidly adding new features to Workspace and are constantly releasing new versions.

Project management should be automatic

One of the nice things with Ant was that any project with a build.xml was automatically included in the build. If you've used Gradle, you know that everything needs to be manually included in the settings.gradle file. I found this annoying coming from the Plugins SDK.

To combat this, we applied the Workspace Gradle plugin, which automatically adds projects as long as they have certain heuristics that let us determine they match the right folder. For example, modules should have a BND file, themes should have a Gulp file, WARs (which were a little harder to determine) should contain a source folder, etc. If they meet this criteria, they’re added to your project build.

Everyone should be on the same environment

The hardest thing about using the Plugins SDK was ensuring everyone was using the same thing. Bundles were configured individually. Everyone had a different version of Ant installed. Configurations were all over the place.

The best thing about using a Gradle project is that you don't need Gradle installed to use it. We took that concept further and allowed Workspace users to download a bundle and configure it all as part of the build process. This means that every developer used the same Liferay Portal version. This also means that if certain parts of the Portal needed to be configured in a similar fashion, the project could configure it for everyone. Moreover, this means that CI could more effectively join the build process because it was running the same things as everyone else.

You should decide your own build tools

One thing the Plugins SDK never gave you was a choice. You had to use Ant to build all your plugins using Ant even if the tool wasn’t the best tool for the job.

In Workspace, we decided to be more flexible with our tools. You can build your theme using Node or the build tool.  If you still need to use the Plugins SDK for legacy portlets, we’ve provided backwards compatibility.  And if you don’t want to use Gradle at all, we’ve provided a Maven version of Workspace. Surprise!

Providing a Maven Workspace was not part of our initial vision, but as we began to work out our Maven story, it made more and more sense. We finally published the archetype this week. If you would like to try it, execute

mvn archetype:generate -DarchetypeGroupId=com.liferay -DarchetypeArtifactId=com.liferay.project.templates.workspace -DarchetypeVersion=1.0.2

For documentation (sorry, the Maven Workspace docs are coming): https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-0/improved-developer-tooling-liferay-workspace-maven-plugins-and-more

For an example of it in use (includes examples of Maven):

https://github.com/david-truong/liferay-workspace

Please try out the different versions of Workspace. We are eager to hear your feedback.