openliberty / liberty-tools-eclipse

Welcome to the Liberty Tools for Eclipse IDE project

A Liberty plugin for the Eclipse IDE. The plugin allows you to run your Liberty Maven or Liberty Gradle projects in dev mode through the Liberty dashboard view or through the project explorer view. You can start, stop, or interact with Liberty dev mode on all configured Liberty Maven and Liberty Gradle projects in your workspace.

---

• Quick start
• Features
• Action commands
• Contributing
• Issues

Liberty dashboard

Maven Projects	Gradle Projects

Explorer view

Quick start

• Understand the prerequisites
• Install Liberty Tools.
• Install your Maven or Gradle application.
• Open the Liberty dashboard view by clicking on the Open Liberty icon on the toolbar, or open the project explorer view.
• Right-click on your application in the Liberty dashboard to view the available action commands. If you are using the project explorer view, right-click on your application and select the Run As entry on the menu to view the available Liberty launch shortcuts.

For detailed instructions on how to use the Liberty dashboard context menu commands or the Liberty launch shortcuts in the project explorer view, check out the User Guide page.

Features

• View supported projects in the dashboard.
• Start and stop dev mode.
• Start dev mode with custom parameters.
• Start dev mode in a container.
• Start dev mode with the debugger attached.
• Run tests.
• View test reports.
• Code with language assistance in the following configuration and application files:
  • server.xml, server.env, and bootstrap.properties Liberty configuration files
  • Jakarta EE 9.x APIs in Java files
  • MicroProfile APIs in microprofile-config.properties and Java files

The following screen captures demonstrate some of the Liberty Tools language assistance features.

Code completion in server.xml files helps you quickly edit your Liberty runtime configuration.

Similar code assistance is provided for bootstrap.properties files (and server.env though not shown):

Helpful code snippets are provided in Java files for Jakarta EE APIs such as Jakarta RESTful Web Services.

Code completion for microprofile-config.properties files helps you easily set properties for MicroProfile APIs.

Editing assistance for configuration and application files is provided through the following language server projects, which this project consumes. For more information, see the documentation for these projects.

• Liberty configuration files: Liberty Config Language Server
• Jakarta EE APIs in Java files: Eclipse LSP4Jakarta, the Language Server for Jakarta EE.
• MicroProfile APIs in microprofile-config.properties and Java files: Eclipse LSP4MP, the Language Server for MicroProfile.

Action commands

Action command	Description
Start	Starts dev mode.
Start in container	Starts dev mode with the server in a container.
Start...	Opens the Run Configurations dialog to customize and run dev mode. You can find the supported parameters in the documentation for the dev goal of the Liberty Maven Plugin and the libertyDev task of the Liberty Gradle Plugin.
Debug	Starts dev mode and attaches the debugger to the server JVM running the application.
Debug in container	Starts dev mode with the server in a container and attaches the debugger to the JVM within the container.
Debug...	Opens the Debug Configurations dialog to customize and run dev mode, and attaches the debugger to the server JVM that is running the application.
Stop	Stops dev mode.
Run tests	Runs the unit tests and integration tests that are configured for your project. This command requires that dev mode is already started.
View integration test report (Maven)	Opens the integration test report file if it exists at /target/site/failsafe-report.html. This action command is only available to Maven projects.
View unit test report (Maven)	Opens the unit test report file if it exists at /target/site/surefire-report.html. This action command is only available to Maven projects.
View test report (Gradle)	Opens the test report file if it exists at the default location: build/reports/tests/test/index.html. This action command is available only to Gradle projects. Unlike Maven projects, Gradle projects have only a single action command for test result reporting.

Contributing

Contributions to the Liberty Tools for Eclipse IDE plugin are welcome!

Our CONTRIBUTING document contains details for setting up your development environment and submitting pull requests.

Issues

Please report bugs, issues and feature requests by creating a GitHub issue

liberty-tools-eclipse's Issues

Code scans for early release

We basically have secured internal approval. We might do one more round of scans as we see the need.

Create early release install artifacts - update README to reference it.

Probably going to be:
http://github.com/OpenLiberty/liberty-tools-eclipse-install

It'd probably be helpful to make the zip available too. We could likely use a GitHub Release for that. It might actually make more sense to add the GitHub Release from this current main repo rather than the special install repo, since someone might look here first. We can add a pointer to the install repo.

Factor out NLS messages for translation

Move user-facing message text to a separate file in preparation for doing translation.

Add support for consuming Liberty LS bootstrap.properties and server.env from appropriate editors.

For this let's wait until https://github.com/OpenLiberty/liberty-language-server releases a pre-req into Maven. (which is tracked also as #84)

feature.xml - require import stanza

currently feature.xml in liberty-mpls does not contain a requires-import stanza listing the mpls.jdt.core plugin (and others) but catagory.xml does specify a install repository for that plugin. (and others)

The liberty-mpls plugin does install and the required dependency plugins install as well form the update site built during the build.

Investigate if this is correct - or do we need an entry in feature.xml as well?

Produce final 'about.html' for Liberty LS lemminx extension (for NOTICE info).

On a related note see: OpenLiberty/liberty-language-server#131
(With this we might be able to remove our use of the shade plugin to strip out the NOTICE in there:

For snippet code gen via MP LS, fix template variables getting written into Java w/o substitution

When inserting snippet code via the MP LS snippet support, well known LS template vars supported by the MP LS in snippet code are not resolved and appear as is in the generated snippet code. These vars need to be resolved (probably via the underlying LS 4 Eclipse (LS4E) layer.

example - this liveness snippet insert:

import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;
import org.eclipse.microprofile.health.Liveness;

import javax.enterprise.context.ApplicationScoped;

@Liveness
@ApplicationScoped
public class ${TM_FILENAME_BASE} implements HealthCheck {

	@Override
	public HealthCheckResponse call() {
		return HealthCheckResponse.named(${TM_FILENAME_BASE}.class.getSimpleName()).withData("live",true).up().build();
	}
}

${TM_FILENAME_BASE} is a LS template var that should be resolved to a value when inserted.

Print "header" showing project path, mvn vs mvnw, any other info to Terminal session

Not sure how to do this.

Considerations for project migrations

Consider what we should do for classic projects that work in Eclipse IDE and with classic Liberty Developer Tools. e.g., do we need to help migrate them over to be Maven or Gradle-based projects to work with dev mode and tools?

Populate"Liberty" projects on dashboard upon project import (configurator?)

From the IntelliJ design linked off OpenLiberty/open-liberty#14957 we see the design decision:
The Liberty tool window displays a list of Liberty projects in the current workspace with the Liberty Maven Plugin or Liberty Gradle plugin configured.

Another idea though, at least for Maven, would be to offer the dev mode tooling simply for any WAR module. That might have a neat side effect of emphasizing how easy it is to start using Open Liberty. We can discuss more.

Missing trace preference when using "for Java developers" Eclipse package (non-Enterprise) - doc or install prereq?

We should measure both install time and disk footprint of

Enterprise Java + LT as-is
vs.
Plain Java + LT-with-needed-prereqs.

It seems at least Wild Web Developer would be needed in the latter (I don't think it's in the core plain Java distro). It seems m2e and Gradle/buildship would be too (not sure if they're in Java distro).

Capture multi-module relationship btw. aggregator/aggregate on project display in dashboard... e.g with some kind of tree view and/or ability to expand/collapse "twisties"

Rework "Liberty nature" detection of Liberty projects to key off of server.xml presence

On dashboard open (or refresh), inspect all workspace projects and add Liberty Tools Nature:

• IF projects has Maven nature (or pom.xml) or Gradle nature (or build.gradle)
  • AND project has src/main/liberty/config/server.xml
  • OR <subdir>/src/main/liberty/config/server.xml (for multi-module)

One downside of this scheme is that, for a multi-module project the child will be added to and the user will have to know to run from the parent.

NATURE

"Liberty Tools Nature" (name in "Project Natures" menu)
io.openliberty.tools.libertyToolsNature

ALSO

we should never remove the nature on refresh, in case the user has manually added it.

Indicate Maven vs. Gradle project in dashboard display (via icon, etc.)

Add ability to view Liberty logs from dashboard (or project)

Would be nice to be able to open up messages.log and not have to rely on eyeballing the terminal view.

Dev mode terminal should pop up to foreground when Run Tests action selected from the dashboard

LS functionality should be available in the Java Editor within eclipse

Currently only a subset of LS functions appear to work when a file is opened in the Java Editor in eclipse. All LS functions work when a file is opened in the Generic Editor, however.

Need to understand why this is and ensure that all LS function is working when a java part is opened in the Java Editor.

Automated test for end user install

Moving out of milestone.

Dashboard can't stop/start after a Ctrl+C is used to stop dev mode within a terminal

After I do Ctrl+C, I can't start again; I get:

But I can't issue a stop either:

Add multi-module test for early release import

Use something like: https://github.com/OpenLiberty/guide-maven-multimodules

I think based on the design in #63 we should see both the parent as well as the module containing the EAR show up on the dashboard.

Show status (stopped or started) and debug port of each app in the dashboard

We could potentially leverage the LMP and LGP's "liberty:status" commands to see if each server/app is started and reflect that in a "status" column next to each app in the Liberty Dashboard.

Loading menu icon fails if JSF tagsupport bundle not present

We seem to have an undeclared prereq, in bundles/liberty/src/liberty/tools/ui/DashboardView.java where we do:
new URL("platform:/plugin/org.eclipse.jst.jsf.standard.tagsupport/icons/palette/Composite/small/ACTIONSOURCE.gif"));

If the plugin isn't present we see a red square in place of the icon. Maybe we're loading in a non-OSGI-friendly way?

Code signing for early release

Investigate: remove intermediate env vars: MAVEN_HOME, M2_MAVEN, GRADLE_HOME unless they are truly standard

In DevModeOperations.java:

• getGradleInstallHome()
• getMavenInstallHome()
  we currently look for special env vars: MAVEN_HOME , M2_MAVEN, GRADLE_HOME.

---

Do we have any reference for treating these variables specially?

As far as I can tell they are not used in any special way by the Maven/Gradle tooling itself (as the Maven link shows M2_HOME was used until Maven 3.5).

• https://discuss.gradle.org/t/do-we-really-need-gradle-home-docs-site-inconsistency/21671/4
• https://maven.apache.org/docs/3.5.0/release-notes.html

If we are introducing these variables ourselves, essentially, we should remove them and just rely on PATH.

Use "recent editor tabs/windows" as context to connect hotkey command back to a particular project

At the Early Release level, you must have a single project selected before issuing a hotkey command, so our UI plugin can connect the command to a particular project (out of the full list present in the dashboard).

Perhaps we can scope the hotkey command to a particular project by somehow accessing recent tabs as context. (I haven't confirmed this is possible, so this needs an investigation to begin).

Terminal tab shows error on workspace restart

java.lang.NullPointerException
at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
at liberty.tools.ui.terminal.ProjectTabController.getProjectConnector(ProjectTabController.java:130)
at liberty.tools.ui.terminal.LocalDevModeLauncherDelegate.createTerminalConnector(LocalDevModeLauncherDelegate.java:38)
at org.eclipse.tm.terminal.view.ui.services.TerminalService.createTerminalConnector(TerminalService.java:246)
at org.eclipse.tm.terminal.view.ui.services.TerminalService.executeServiceOperation(TerminalService.java:168)
at org.eclipse.tm.terminal.view.ui.services.TerminalService.openConsole(TerminalService.java:258)
at org.eclipse.tm.terminal.connector.local.launcher.LocalLauncherDelegate.execute(LocalLauncherDelegate.java:224)
at org.eclipse.tm.terminal.view.ui.view.TerminalsViewMementoHandler.restoreState(TerminalsViewMementoHandler.java:200)
at org.eclipse.tm.terminal.view.ui.view.TerminalsView.restoreState(TerminalsView.java:616)
at org.eclipse.tm.terminal.view.ui.view.TerminalsView.init(TerminalsView.java:338)
at org.eclipse.ui.internal.ViewReference.initialize(ViewReference.java:129)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:344)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:58)
at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:995)
at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:960)
at org.eclipse.e4.core.internal.di.InjectorImpl.internalInject(InjectorImpl.java:140)
at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:403)
at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:330)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:202)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:91)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:60)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:42)
at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:132)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:994)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:658)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$1.run(PartRenderingEngine.java:543)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:527)
at org.eclipse.e4.ui.workbench.renderers.swt.ElementReferenceRenderer.createWidget(ElementReferenceRenderer.java:73)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:994)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:658)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:762)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:727)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:711)
at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.showTab(StackRenderer.java:1209)
at org.eclipse.e4.ui.workbench.renderers.swt.LazyStackRenderer.postProcess(LazyStackRenderer.java:116)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:676)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:762)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:727)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:711)
at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.processContents(SWTPartRenderer.java:71)
at org.eclipse.e4.ui.workbench.renderers.swt.SashRenderer.processContents(SashRenderer.java:150)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:672)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:762)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:727)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:711)
at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.processContents(SWTPartRenderer.java:71)
at org.eclipse.e4.ui.workbench.renderers.swt.SashRenderer.processContents(SashRenderer.java:150)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:672)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:762)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:727)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:711)
at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.processContents(SWTPartRenderer.java:71)
at org.eclipse.e4.ui.workbench.renderers.swt.PerspectiveRenderer.processContents(PerspectiveRenderer.java:51)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:672)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:762)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:727)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:711)
at org.eclipse.e4.ui.workbench.renderers.swt.PerspectiveStackRenderer.showTab(PerspectiveStackRenderer.java:82)
at org.eclipse.e4.ui.workbench.renderers.swt.LazyStackRenderer.postProcess(LazyStackRenderer.java:116)
at org.eclipse.e4.ui.workbench.renderers.swt.PerspectiveStackRenderer.postProcess(PerspectiveStackRenderer.java:64)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:676)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:762)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:727)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:711)
at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.processContents(SWTPartRenderer.java:71)
at org.eclipse.e4.ui.workbench.renderers.swt.SashRenderer.processContents(SashRenderer.java:150)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:672)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:762)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:727)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:711)
at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.processContents(SWTPartRenderer.java:71)
at org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer.processContents(WBWRenderer.java:658)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:672)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:762)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:727)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:711)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1078)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1041)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155)
at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644)
at org.eclipse.ui.internal.Workbench$$Lambda$190/0000000000000000.run(Unknown Source)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:596)
at org.eclipse.equinox.launcher.Main.run(Main.java:1467)
at org.eclipse.equinox.launcher.Main.main(Main.java:1440)

Rename/refactor packages and XML identifiers to use 'io.openliberty.tools.eclipse' prefix

First, the feature name should simply be "Liberty Tools" and the category should be "Liberty Tools" as well.

An additional list of parts to change:

1. OSGi bundle manifests:

• UI Bundle - io.openliberty.tools.eclipse.ui
• Language Server Bundle - io.openliberty.tools.eclipse.lsp4e

2. Other Eclipse installable feature files like feature.xml, category.xml
3. plugin.xml extension id(s), e.g. key commandId="liberty.commands.open.dashboard"
4. pom.xml groupid (even though I'm not sure which if any of these artifacts need to go to Maven Central).
5. Finally we should also change the package prefix and filenames of Java parts

I did the feature rename plus some of 1,2,4 (though none of 3.) in https://github.com/scottkurz/liberty-dev-tools-eclipse/tree/name-versions
e..g see:
58678dd?w=1
and the second commit which renames the feature file

Also note in this branch the convention needed to have Tycho release a non-snapshot version

As a user of the Eclipse tooling, I want to have an easy way to see my server logs (messages.log at least, maybe trace.log)

The WDT tooling offered this via the Servers view, IIRC.

Implement Accessibility features

Launch Maven/Gradle with JAVA_HOME set by preferring JAVA_HOME then java.home sysprop

From project right-click menu, add ability to make a Liberty project

Do things like:

• add the latest LMP/LGP version
• add Liberty nature
• generate server.xml if not present

Re-enable "testRefresh" tests for Maven and Gradle

The "testRefresh" tests use Files.copy() to copy test versions of the pom.xml and build.gradle files. On Windows, these operations can hang.

Add debug logging to mvn/gradle executable location (incl wrappers) and other high priority areas

E.g. see:
https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Flaunchers%2Ftracing.htm&cp%3D4_3_3_0_4

Publish update site install to DHE and offer Eclipse Marketplace Client support

Refer to dev mode as "dev mode"

We refer to dev mode as "dev mode" instead of "development mode". Should update where "development mode" is used to be "dev mode".

https://openliberty.io/docs/latest/development-mode.html

We may explain it as a mode for development for developers but the documented (proper) name is "dev mode".

Construct feature installation for early release

• 1. It should include
  • Liberty dev dashboard
  • lsp4mp release content
• 2. We should have naming & versioning with some level of socialization, internally at least
• 3. Provide Eclipse Marketplace Client info
• 4. Import mpls.jdt.core plugin
• 5. prereq the Wild Web Developer Tools (not sure how this is enforced)
• 6. prereq the lsp4e.jdt plugin

Slow response when stop is issued during early startup

Is the purpose of 'stop' is to stop cleanly with the 'q' rather than Ctrl+C ? Or is the purpose just to stop as quickly as possible?
E.g. from a regular terminal, 'q' is quicker than Ctrl+C..since for the latter, I need to hit 'Y' to another prompt (are you sure you want to cancel).
On my windows shell at least I get:

INFO: Server defaultServer stopped.
Terminate batch job (Y/N)?

However.. I can only issue 'q' once dev mode reaches the point where it's listening for this. With Ctrl+C, OTOH, I can cancel at any time.. even "early" before dev mode is listening.
Would there be any value in implementing "stop" more like Ctrl+C plus answering 'Y'? Something to think about.

Early Release - Getting started article / video

optional parameters should appear before "liberty:dev" on constructed cmd line

I should be able to do:

mvn myplugin:somegoal liberty:dev

it looks like the code orders this the wrong way around.

Behavior on command menu selection after more than one project has been selected is unclear.

If I select >1 project like here:

and do "Start" then what should happen?

When I've tried this I seem to always take the action on the first (top-most) project.

But what SHOULD happen? Should I not be allowed to select more than one?

Taking the action on the top project isn't a horrible behavior, if we are indeed reliably doing this.

But an even more natural behavior would probably be to take the action on EACH project one at a time.

Capture unexpected exceptions in error log

move to a 2202-03 level for plugins in target-platform

unify the target-platform to use plugins form the 2202-03 eclipse download site.

Add debug configuration to dashboard (for user to debug Liberty at default port 7777 )

Only going to work if the default port is used. Fairly trivial to create themselves but still possibly useful.

Should we load server.xsd based on the version of installed Liberty, latest Liberty, something in pom.xml?

Provide user a collapsed view of the src/main/liberty/config folder holding server.xml

Instead of having to navigate thru the dir structure to get to the well-known location: src/main/liberty/config it should be collapsed for me, at least in certain views like maybe Enterprise Explorer?

Note this could be accomplished via:

1. Adding this to the .classpath file: classpathentry excluding="**" kind="src" output="target/liberty/wlp/usr/servers/defaultServer" path="src/main/liberty/config"/>
2. -> New -> Source Folder -> src/main/liberty/config Could 1. possibly be worth adding to the starter (generating the whole .classpath just for this?) Seems maybe less than desirable. I wonder if there's a better way.

Associate XML files with Generic Text Editor to get full lemminx LS support

Support dashboard command opening test reports at non-default locations

For Gradle we would handle in the general case a path: test.reports.html.destination

For Maven I think the most typical way for a non-default path would use the <reporting> element

Clean up liberty-maven-test-app/.project from test run?

The .project file is created on import during the test run.

To the extent the test is supposed to verify the creation with the Liberty nature, the fact that it's left behind means subsequent executions in-place aren't verifying the exact same thing (though a clean run in CI certainly would).

This has a miniscule chance of causing much of a real problem. But I think it's valuable to think more about test lifecycle and what we are and aren't assuming about test preconditions...so leaving this open to think about at least.

Maybe the file should be deleted before the test runs start.

Indicate whether server is active/running via dashboard display (icon, etc.)

One challenge here is to understand if we need to distinguish whether the server is running because we started it ourselves vs. it was started in some other way. Do we simply reflect what we've done or do we look in the server dir for the appropriate marker file?

From dashboard, add ability to open a Terminal in the current project path

Debatable since you can already do this from many views, e.g. Package Explorer