History of the Liferay IDEs

I first started developing for Liferay version 4.2.3. Back then, we used what was called the "extension environment" to handle Liferay customization. This was an Ant-based environment with fairly complicated build scripts that was responsible for building the deployable Liferay.

And we were building portlets per the portlet specification, creating portlet war files and ended up being many different XML files to edit and maintain.

And of course there was Service Builder, and it had its own XML files to define entities and spring beans.

With Liferay 5, we switch to the Liferay SDK, another Ant-based environment. The builds of artifacts like themes, hooks and portlets happened outside of the Liferay tree, but there was still a lot of XML files to manage.

Going into Liferay 6 we had an updated SDK, but all of the XML files were still in the picture.

Along the way we finally got Maven archetypes for building Liferay assets so we could get out of the SDK, but we still had all of the XML files that we had to deal with.

Throughout these different Liferay version changes, Liferay realized that they could improve developer productivity by creating a custom IDE with friendly UIs to replace the direct XML editing.

First we were all using the Liferay IDE (a regular Eclipse plugin) or we were using Liferay Developer Studio or LDS (an enhanced version of the IDE for Liferay EE developers). Once Intellij came out and developers started to upgrade (that comment is for you, Olaf!), Liferay created a plugin for Intellij.

OSGi Changes Everything

In Liferay 7, OSGi was fully embraced. Liferay even changed how portlets were packaged, dropping the portlet war files with lots of XML and moving to OSGi jars and classes with @Component annotation properties.

At the same time, we got the Blade tool and the Liferay Workspace. Blade is a CLI for creating new workspaces and scaffolding new modules from templates, and the Liferay Workspace is a Gradle-based (and for some time a Maven-based) area to organize Liferay customizations and builds.

The only real XML file that was left over from the old days was the Service Builder service.xml file; the rest were not necessary unless you were still building legacy portlet wars.

But Liferay kept the IDEs... Now, however, instead of doing anything useful, the UIs would present an interface but would invoke the Blade CLI tool to do all of the work. Basically a lot of effort to build and maintain the IDEs with some benefit, but very little.

Client Extensions are the Nail in the Coffin

The days of a custom Liferay IDE/plugin are numbered, and Client Extensions are the nail in the coffin.

With Client Extensions, the custom UIs in the IDEs have little value. Since you should create CX instead of OSGi modules, creating a new module in the IDE through invoking Blade is not necessary.

Because we recommend using Objects in lieu of Service Builder, the service.xml file is no longer necessary.

And for times where you might need an OSGi module or a Service Builder API, since the Blade CLI is still available and the service.xml file can be used to generate services, just because there wouldn't be a custom UI for these things wouldn't mean the capabilities they provided were gone.

Conclusion

I predict that, some time soon, Liferay will announce that the Liferay IDE, LDS and the Liferay Intellij plugin are all going to be deprecated and no longer supported or updated.

For what it's worth, I'm one of the voices pushing for this. Our dev tools team is small and has limited resources, and there are things that we really need them to focus on (Blade CLI updates to handle the quarterly releases, workspace plugin updates for current and new CX types, tooling updates for JDK 21, etc.).

The team just doesn't have the capacity to get the things done that we must have as well as maintain custom IDEs for things we're not recommending anymore.

So yes, [I hope] it is the end of days for the custom Liferay IDEs.

I will miss them, of course, but their time has come and gone.

Share your thoughts on whether we need the Liferay IDEs below...