Ivano Carrara 1 Month 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. Reply as... Cancel David H Nebinger Ivano Carrara 1 Month 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. Reply as... Cancel Ivano Carrara David H Nebinger 1 Month 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. Reply as... Cancel David H Nebinger Ivano Carrara 1 Month 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. Reply as... Cancel
David H Nebinger Ivano Carrara 1 Month 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. Reply as... Cancel Ivano Carrara David H Nebinger 1 Month 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. Reply as... Cancel David H Nebinger Ivano Carrara 1 Month 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. Reply as... Cancel
Ivano Carrara David H Nebinger 1 Month 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. Reply as... Cancel David H Nebinger Ivano Carrara 1 Month 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. Reply as... Cancel
David H Nebinger Ivano Carrara 1 Month 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. Reply as... Cancel
Martin Vaněk 1 Month 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. Reply as... Cancel David H Nebinger Martin Vaněk 1 Month 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. Reply as... Cancel Martin Vaněk David H Nebinger 1 Month 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. Reply as... Cancel David H Nebinger Martin Vaněk 1 Month 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. Reply as... Cancel
David H Nebinger Martin Vaněk 1 Month 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. Reply as... Cancel Martin Vaněk David H Nebinger 1 Month 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. Reply as... Cancel David H Nebinger Martin Vaněk 1 Month 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. Reply as... Cancel
Martin Vaněk David H Nebinger 1 Month 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. Reply as... Cancel David H Nebinger Martin Vaněk 1 Month 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. Reply as... Cancel
David H Nebinger Martin Vaněk 1 Month 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. Reply as... Cancel
Christoph Rabel 1 Month 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. Reply as... Cancel David H Nebinger Christoph Rabel 1 Month 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. Reply as... Cancel
David H Nebinger Christoph Rabel 1 Month 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. Reply as... Cancel
Terry Jia 1 Month 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. Reply as... Cancel David H Nebinger Terry Jia 1 Month 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. Reply as... Cancel
David H Nebinger Terry Jia 1 Month 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. Reply as... Cancel