Featured Platform

IDEs: To Be or Not To Be

That is the question - do we still need the Liferay IDE, Liferay Developer Studio or the Liferay Intellij Plugin?

thumbnail
David H Nebinger
Published Date8 Months Ago - 3385 Views

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...

liferay-ide lds intellij
Comment (12)

More Blog Entries

thumbnail

Session Auto-Extend Properties are now in Configuration

thumbnail
David H Nebinger
18 Mar
0
thumbnail

How to Update Email Address and Screen Name with Groovy Scripts

thumbnail
saravanan muniraj
25 Mar
0
Blogs
thumbnail
Ivano Carrara
8 Months Ago - Edited

Thank you David for the valuable article to guide us on the future of Lferay. ​​​​​​​ Since Client Extensions are the nail in the coffin, can you please tell us where we find the documentation to guide the development of Client Extensions?

Please sign in to reply.
thumbnail
David H Nebinger Ivano Carrara
8 Months Ago - Edited

Hi Ivano!

We have a lot of documentation already on learn.liferay.com, but we recognize that there are some gaps and more detail that we need to fill in.

Over this year we are planning to add more CX-related content to learn.liferay.com to address those concerns.

And, of course, there will be other efforts (I have one blog post in the works about CX so far, and of course you can reach us by posting on Ask or in the Community Slack, we'll be working on new webinars and bootcamp materials to cover CX, etc.) as the year goes on...

Please sign in to reply.
thumbnail
Ivano Carrara David H Nebinger
8 Months Ago - Edited

Hi David, thank you for your comment.

Since January 2004 I have been using Liferay in my projects. On June 2007 I asked and obtained the opening of a new category within Liferay Forum addressed to Italian speaking users and I wrote the first post in it. So I witness that the work that has been done on the documentation since the release of Version 7.2 and especially around Version 7.4 is incredible. Before Version 7 the documentation was not well maintained and the quantity was limited, you know.

You're right when you say there is a lot of documentation already on learn.liferay.com about Client Extensions and I apologize for the previous post. ​​​​​​​I meant that what I was looking for are some blog articles, practical examples and some tutorials around such an important topic as Client Extensions.

Thanks in advance for what developers experienced in this new development method for Liferay will be able to do.

Please sign in to reply.
thumbnail
David H Nebinger Ivano Carrara
8 Months Ago - Edited

Thanks Ivano, no worries!

We're planning a "full court press" on CX this year, so you should see a lot more of those thing coming soon...

Please sign in to reply.
Martin Vaněk
8 Months Ago - Edited

What would happen to running Liferay in debug mode?

Currently the main feature of intellj plugin for me is actually running the server in debug mode. Often times I have to dig into LR code (or mine code ofc) and having the Run Configuration to do so is very convinient. I know I could run it using tomcat scripts and remote debug but that has extra steps for setup (also via run config I can change java version easily, manually I would have to manage it).

Please sign in to reply.
thumbnail
David H Nebinger Martin Vaněk
8 Months Ago - Edited

You just enable remote debugging...

Debugging mode for Liferay is really just the IDE spawning tomcat with debug enabled. Instead, you manually start tomcat in debug mode (it's really just a matter of adding "jpda" to the command line, you can also use "tomcat/bin/catalina.sh debug" to do start in debug mode).

Then, in the IDE, just attach to a "remote" java process. In Intellij, for example, I just use the remote java debugger and connect in.

After that, all of your breakpoints, etc. will still work.

Another alternative, just launch tomcat app server in debug mode in eclipse; the IDE typically just helped with defining where the external server was, but it was never the only way to define an external tomcat instance. You can manually add the tomcat server and then start it in debug mode and still get your breakpoints and what not.

Please sign in to reply.
Martin Vaněk David H Nebinger
8 Months Ago - Edited

Okay, I understand it can be done. I mostly wanted to express my opinion even though the it can be done I still value it pretty highly.

Especially for newer developers (or new to liferay) just adding run config and going to town. Then if you tell them to debug they just click the button and can jump right into their (or Liferays) code.

Having console open up, learning about remote debug, having correct JDK (different OSes for different developers, with different state of their local machine). It all adds extra steps and while I see the learning value, sometimes it is not the priority.

 

Basically from my experience it was pretty invaluable to have it, so I wanted to pitch in with my thoughts.

Please sign in to reply.
thumbnail
David H Nebinger Martin Vaněk
8 Months Ago - Edited

Thanks Martin, and that aspect is an important one certainly.

When I was starting with Liferay, or even as I start with any new and unfamiliar tool, the documentation needs to be there. If there are a lot of steps and twists and turns along the way, I can navigate them if the doco prepares me for them.

For example, I've recently been working on launching a Postgres cluster within a K8s cluster that supports replication, etc. While I know it is possible, I'm relying on documentation and examples and videos, etc., to help me get there.

In this scenario a GUI tool might make it faster for me to launch the Postgres cluster, but it likely wouldn't help me understand what is going on or how to modify or replicate the process.

Please sign in to reply.
thumbnail
Christoph Rabel
8 Months Ago - Edited

I see CX only as a further option to add functionality to Liferay. A useful new feature, but there's a lot of usecases where it is easier to just implement something in Liferay using the LocalServices. I will certainly use CX in the future for some stuff, but I don't see osgi modules going away and we will certainly continue to use them.

On top of that, we already have a lot of existing code and modules that we will need to support for many years to come.

That said, I am not sure a dedicated IDE is needed. I believe a Liferay expert doesn't need it at all, I for one, either use blade or copy an existing module and change it.

But, I also believe, that the IDE is helpful for beginners. The "new project" wizards can be a nice starting point. So, there needs to be a nice way for beginners to start projects (I did not check the current documentation, maybe it's already swell and I am the wrong person to judge it anyway).

And I think, there is one hard requirement: Java 17+ support for Liferay. Which is probably also a blocker for a new IDE version, since Eclipse needs Java 17.

Please sign in to reply.
thumbnail
David H Nebinger Christoph Rabel
8 Months Ago - Edited

OSGi customization cannot go away as it is the only way to affect customizations.

Blade can and does handle the module and workspace tasks already (via the IDE plugins), so this really just takes the IDE out of the picture and uses the command line to accomplish the same things.

For the beginners and "new project" wizards, as long as we do a better job documenting how to use Blade and how to refresh workspaces and what not, I think we can cover those pretty well.

If the success of a beginner or a new project is due solely to a customized IDE, I'd argue that there's a bigger problem there that the IDE alone cannot and does not solve.

Please sign in to reply.
Terry Jia
7 Months Ago - Edited

As the initiator of the IntelliJ IDEA Plugin and a former core IDE member, it is super sad to see Liferay may decide to let the IDEs die. I still remember the hardworking nights spent analyzing how to implement the Liferay project running inside IntelliJ IDEA.

Even though I don't work for Liferay now, I still work on Liferay projects with these tools I created every day. From a daily Liferay project worker's perspective, I can come up with many ideas for the IntelliJ IDEA Plugin.

For example, a common request is running the Groovy script in IntelliJ IDEA and getting the output directly instead of copying and pasting into the browser->Control Panel -> Server Admin -> Script repeatedly (You can find I opened a GitHub issue https://github.com/liferay/liferay-intellij-plugin/issues/232 regarding this feature, among many others), not to mention adding Client Extension support inside IDEA.

I would not like to judge whatever Liferay decides to make, but maybe the best course of action is to move these tools into the open source community's hands and keep them alive with users who are still keen to utilize them in their Liferay projects.

Please sign in to reply.
thumbnail
David H Nebinger Terry Jia
7 Months Ago - Edited

That's kind of the problem, Terry. There is no one left to support and maintain the plugin, and the new recommended development path for Liferay lies outside of Liferay anyway, so the usefulness of the plugin for that scenario has been greatly diminished.

You and others did fantastic work supporting the IDEs and plugins at times where they were necessary, and you should all be commended for your contributions.

As far as them "moving tools into the open source community", as you noted the repo is publicly available to fork and maintain, I don't think you'd need to worry about Liferay preventing that in any way.

Please sign in to reply.