Liberty Tools

Sorry, I just noticed this.

The dev mode in liberty-maven-plugin does not work with a Spring Boot JAR.

The only way to use dev mode with Spring Boot in Liberty currently is to use a WAR packaging type.  Some of the details are described in this blog post https://openliberty.io/blog/2024/05/01/spring-boot-3.html .  I recognize changing packaging type might not be an option for you though.

Note you should still be able to leverage the Java and server configuration assistance in Liberty Tools even without the ability to launch the app via liberty-maven-plugin dev mode.  

If it helps I'll mention too that you can use liberty-maven-plugin to deploy a Spring Boot JAR to Liberty, (just not in dev mode).  To use this approach you do need an extra configuration element, it should look something like this:
     <plugin>
       <groupId>io.openliberty.tools</groupId>
       <artifactId>liberty-maven-plugin</artifactId>
       <configuration>        
         <deployPackages>spring-boot-project</deployPackages>

This technique is used in the Liberty Spring Boot guide:  https://github.com/OpenLiberty/guide-spring-boot/blob/prod/finish/pom.x…  (using the other synonym for this <deployPackages> configuration parm element, <installAppPackages>).

We don't support 2024-06 yet.  The current latest version of Liberty Tools (v24.0.6) targets 2024-03 and we support the older versions listed above:

Eclipse Versions: 2024-03 (4.31), 2023-12 (4.30), 2023-09 (4.29), 2023-06 (4.28), 2023-03 (4.27), 2022-12 (4.26), 2022-09 (4.25)

I tried a workaround solution, and it worked for me. I tested it in Eclipse 2024-09, but I believe it will also work in the 2024-06 version. First, you need to download the JDT Language Server from this link. Then, extract the tar file and copy the 'plugins' folder into your Eclipse home directory. Now, you can open Eclipse and install the plugin.

Yes, you can still get some value from Liberty Tools Eclipse with a project using an Ant build.  You can get assistance with Liberty server config (server.xml, bootstrap.properties, server.env).   You can also get some assistance for the Jakarta EE 9 APIs via the language server (though you shouldn't expect this assistance to be Spring-"aware").

You would not, however, be able to use the Liberty Dashboard view in Liberty Tools to view and run your app, since these leverage the Liberty Maven/Gradle plugins.   

I'll also mention that we don't test for compatibility or coexistence with any Spring Eclipse tooling (e.g. STS), another thing you might be asking about.  

Good question.  

It's true that most of our tooling and documentation centers around a single application per server, and so, though we don't prevent you from using more than one app per server, the approach here isn't obvious.

So, it is possible to use the code assistance outside of a single, tooling-executable project.  E.g you can use the server.xml code assistance to get completions for adding elements/attributes and Jakarta API quick fixes even without the ability to use a tooling-integrated deployment and server execution.  True, this is less than a first-class experience but can still be helpful.

Another path you could take, assuming you're using Maven, requires a bit of setup work on your part.  

You could create a multi-module project with a 'pom' module which will hold your server.xml configuration (and integration tests) and declare dependencies on your other modules. See here, https://github.com/OpenLiberty/ci.maven/issues/1475#issuecomment-156908… for some more details.  

Please feel free to let us know your thoughts and feedback in this area.

Scott Kurz

There is not an update planned since you don't need one to use the (new) Liberty Tools IDE feature.   In Liberty Tools we take a different approach than the older Liberty/WebSphere Eclipse IDE tooling.   Rather than providing Liberty implementations for constructs like the Target runtime to support things like the Publish operation and management through the Servers view, as in the older Liberty/WebSphere Developer Tools features, we use a different approach.

For Liberty Tools, we assume the use of a Maven or Gradle project.   Compilation is performed against normal Maven/Gradle dependencies and the Liberty Maven and Gradle plugins manage installation of the Liberty runtime and deployment of your application to this runtime.  

So using a Jakarta EE 9-level feature like Jakarta Servlet 5.0 simply requires you to use a Maven/Gradle project with a recent version of the corresponding Liberty Maven/Gradle plugin, a valid dependency in your pom.xml/build.gradle, and the servlet-5.0 feature in your server.xml.

Ross, thanks for your question.    Though Liberty Tools is indeed designed as a next-generation version of IBM Liberty Developer Tools, we do not provide the equivalent function in the same manner.  First and most importantly, with Liberty Tools we assume you're using a Maven or Gradle project configured with either the Liberty Maven or Gradle plugin.   Most Liberty projects are using Maven or Gradle these days, but if not, you would first need to convert your project to Maven or Gradle to make use of Liberty Tools.   With Liberty Tools there is no server under the Servers view; the Liberty server is "embedded" in the Liberty Maven or Gradle plugin.  Also there is no "Publish" operation; the Liberty Maven/Gradle plugin deploys the application to the plugin-managed Liberty server.

I believe it is.

In Liberty Tools for Eclipse plugin, when you select 'Servers' view and try to create a Liberty server, you should see 'WebSphere Application Server Liberty Extended Tools' under 'IBM'. After you installed it, you should see the same functionality like 'IBM Liberty Developer Tools' provides.

You don't really need Maven/Gradle at all, but I suggest everyone should try Maven/Gradle to let your development environment more friendly.

Michael, yes, we are developing Liberty Tools as a next-generation of development tools for Liberty, which we're developing in open source on GitHub. We invite you to try it out and we would be happy to hear your feedback.