Blogs

A little while back, I gave a presentation on a new command line tool that the tooling team was hoping to create to help ease development for Liferay. While we were able to get a working prototype for demonstration purposes we quickly realized that the project would never succeed with the current state of Liferay. The issue was that all of our tools required a bundle of Liferay. This was a huge limitation. One of our goals for this tool was that it would be small and lightweight. Being tied to a full Liferay 300mb+ bundle completely killed the idea.

Our team switched gears to a new goal, tools modularization. Liferay was already all gung ho in the idea of modularizing our core so we continually pushed the idea that part of this effort required pulling out all our tools. The first tool we tried was not pull anything out of core but instead was to create a new tool that wasn’t part of core. We implemented a java wrapper for libsass and switched out the ruby sass compiler. This decreased sass compiling to a tenth of the previous compile times. The great thing about this project is that this wrapper is just a standard jar and can be used in any java project that needs to compile sass.

It was clear that this was the right direction to go and six months later, just about every portal tool has now been extracted from the core including the holy grail of all Liferay tools Service Builder! While this is still a work in progress as some tools still haven’t completely broken free of all core dependencies we are already reaping many benefits from this new found freedom.

One immediate benefit that you guys will see is better support! I remember while I was on a consulting project many years back, we had an issue where our custom service builder plugins didn't have any transactions. It turned out to be a small bug in Service Builder but we had to wait 3 months until the next release of Liferay before we could actually fix the issue. Granted our patching and releases are much quicker these days but you are still at the mercy of a release for current versions of Liferay Portal. But with Liferay 7.0, if we discover a new bug in Service Builder you no longer have to wait till the next release of Liferay to get a bug fix. We can push out a fix to our repo and you guys can grab the new jar right away. It also means new features in tooling aren’t tied to portal releases. If one day a native java implementation of a sass compiler comes out, you can expect a new CSSBuilder that can take advantage right away.

A second benefit we've seen now that most of our tools are available as modules is this has made it easier to create byte-sized projects for building new plugins for Liferay 7.0, namely OSGi bundles to take advantage of the improved modular framework (OSGi) running inside Liferay 7.0. The first part of this effort was to create a "Liferay cookbook" repository to demonstrate how to build "Liferay 7.0 modules using OSGi”. We have cataloged many examples of Liferay 7.0 integration points using various build systems (maven, gradle, bndtools). The plan is for this repository to contain more than 120 integration point examples.

The next part of our "tools modularization" process is with Liferay IDE our official Eclipse plugins. This project Liferay IDE has been around for over five years, but all of the tools have been only available as eclipse plugins and thus only executable as a part of an Eclipse IDE/Workspace. However, along the theme of "modularization" we have decided that going forward we are going to build "tools" that will end up in the IDE in a reusable and more modular way. As an example for Liferay 7.0 we are building a "Project Migrator" tool that will help Liferay developers migrate their 6.2 plugin projects to 7.0. In the past this tool would have only been built as a part of Liferay IDE Eclipse plugins, but now we will build them as a reusable OSGi bundle that can be used either in Eclipse or in other applications/use-cases.

And finally one last benefit of modularization has been that we've retrofitted all of our SDK's to use these tools. Which means we're very close to having all of our SDK's completely independent of a bundle to function and all of our SDK's all call the same code base through their plugins. This has allowed us to create a new SDK based on Gradle. It’s already being bundled with our current Plugins SDK if you want to give it a test run though it’s also still a work in progress.

Now back to where we started, the command-line tool. One thing that we are adding to the blade.tools repo is a new "CLI' called "blade". It will provide a command-line based way to execute these new modular tools like creating, migrating, and deploy Liferay 7.0 modules. It will also leverage the blade repo for stubbing out projects. It's in the very early stages and still much work needs to be done but we're extremely excited that we can finally provide a tool we've envisioned many years ago. Developing for Liferay 7.0 should be easier and more flexible than ever allowing you to pick and choose which way is your preferred method of developing.

Checkout out the repos:

Liferay Portal - https://github.com/liferay/liferay-portal
Sass Compiler (libsass) - https://github.com/liferay/liferay-portal/tree/master/modules/util/sass-compiler-jni
Service Builder - https://github.com/liferay/liferay-portal/tree/master/modules/util/portal-tools-service-builder
BLADE: https://github.com/rotty3000/blade.git
blade.tools: https://github.com/gamerson/blade.tools.git

The next time we discuss why modularity matters, we’ll focus on our compatibility matrix.