Integrated set of Liberty tools for developers downloadable from Eclipse IDE's marketplace

[yeekangc]

Description

Enable developers that use Eclipse IDE as their IDE to pull down and install from its marketplace an integrated set of tools to code/build/test/debug their Java applications on top of Liberty easily and iterative fast (rapid inner loop) using APIs like Jakarta EE and MicroProfile.

Solution involves creating an Eclipse IDE plugin for Liberty that enables developers to easily create and develop cloud-native Java applications with Liberty in Eclipse IDE.

Plugin should include:

• Integration with dev mode (e.g. to start/stop Liberty and make iterative changes with dev mode)
• Assistance to edit Liberty configuration files (via Assistance for editing Liberty configuration #14054)
• Pull down language servers (e.g. Language Servers for Jakarta EE and MicroProfile) that provide coding assistance for programming models supported by Liberty that are currently available

---

Note on Checklist for non-runtime feature

Took some liberties in deleting, ignoring, marking N/A sections that did not seem to apply to a tooling (rather than a runtime) deliverable, while realizing this isn't the only way to interpret or map the runtime process onto tooling. Still left some aspects like the ID and SVT focal approval, and of course the whole UFO process.

---

Documents

• Aha: Externally raised RFE - N/A
• UFO: https://ibm.box.com/s/curdb0qg6su1jgtn4yhlf95m49hhkuu2
• FTS: Feature Test Summary - Liberty Tools Eclipse - 23.0.6 Epic liberty-tools-eclipse#426
• Beta Blog: Blog post for Liberty Tools' Dec 2022 refresh blogs#2796
• GA Blog: Blog post: Updates for Liberty Tools and Liberty build plugins blogs#3184

---

Design

Design Preliminaries

• ID requirements identified. (Epic owner / Feature owner with ID focal point) Doc issue
• Serviceability Requirements Identified. (Owner and Serviceability focal point)
• SVT Requirements Identified. (Epic owner / Feature owner with SVT focal point) SVT epic
• Performance testing requirements identified.

Design

• POC Design / UFO review requested.
• POC Design / UFO review scheduled.
• POC Design / UFO review completed.
• POC / UFO Review follow-ons completed.
• POC Design / UFO approval requested.
• Design / UFO approved.
  • The UFO must always accurately reflect the final implementation of the feature. Any changes must be first approved. Afterwards, update the UFO by creating a copy of the original approved slide(s) at the end of the deck and prepend "OLD" to the title(s). A single updated copy of the slide(s) should take the original's place, and have its title(s) prepended with "UPDATED".

FAT Documentation

• "Feature Test Summary" child task created

Legal and Translation

In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. Both MUST be completed before Beta or GA is requested.

Legal (Complete before Feature Complete Date)

• Changed or new open source libraries are cleared and approved, or N/A. (Legal Release Services/Cass Tucker/Release PM).
• Licenses and Certificates of Originality (COOs) are updated, or N/A:
• OUR WORK: Went through initial PTC scan in October. Delta scan will happen 11/25. The license is EPL 2 since this is an open source offering, and there will be no COO.

Translation (Complete 1 week before Feature Complete Date)

• N/A

Innovation (Complete 1 week before Feature Complete Date)

• Consider whether any aspects of the feature may be patentable. If any identified, disclosures have been submitted.

---

Beta

In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.

Beta Code

• Did release as Early Release as noted in beta blog post

GA

A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.

Feature Complete

• Feature implementation and tests completed.
  • All PRs are merged.
  • All epic and child issues are closed.
  • All stop ship issues are completed.
• Legal: all necessary approvals granted.
• [X ] Translation: N/A
• GA development complete and feature ready for inclusion in a GA release

Focal Point Approvals (Complete by Feature Complete Date)

• Demo Demo is scheduled for an upcoming EOI or N/A.

Design Approved Features

• ID Documentation
• Performance: N/A
• Serviceability: N/A
• STE: N/A
• SVT
  • Approver adds label focalApproved:svt.

GA Blog (Complete by Feature Complete Date)

• GA Blog issue created and populated

---

Other Deliverables

• Standalone Feature Blog Post N/A
• OL Guides N/A
• Dev Experience Developer Experience & Tools work is complete or N/A. (OpenLiberty/dev-experience-assessment)

[yeekangc]

Broke down the original into:

• Integrated set of Liberty tools for developers downloadable from IntelliJ IDEA's marketplace #14957 for IntelliJ
• Integrated set of Liberty tools for developers downloadable from VS Code's marketplace #14958 for VS Code/Eclipse Che
• Integrated set of Liberty tools for developers downloadable from Eclipse IDE's marketplace #10352, which is the original issue but re-purposed for Eclipse IDE

Other capabilities like below will be tracked via separate issues (epics):

• Configuration assistance for Liberty through a Language Server for Liberty - Assistance for editing Liberty configuration #14054
• Integration with Liberty Starter (i.e. to create new starter project)
• Consider the use of Remote Server Protocol - Adopt Remote Server Protocol liberty-tools-vscode#56

[mbroz2]

Created https://github.com/OpenLiberty/liberty-dev-tools-eclipse

[scottkurz]

@yeekangc - should we rename this an "early release" feature/issue so we can link it to a distinct UFO from the ultimate final release?

I think we want to target:

• Integration with dev mode - Maven/Gradle
• Integration with MicroProfile Language Server

but not necessarily the Jakarta LS project (which is not as far along as MP LS).

[yeekangc]

I created #21055 to track the "early release", @scottkurz.

[cthigh]

UFO Socialization Part 1 - October 14, 2022

Presenter: Scott Kurz

Notes:

• Page 21

  • The prereqs on this page Implies that customers modernizing would need a separate Eclipse to run these tools.
  • Perhaps there should be clarification that a new installation of Eclipse might be needed to run these Liberty Tools (I.e. no intent of supporting older Eclipse versions)

Page 31

• Revisit the overload of using the start command to run the mvn command. Concerns on this this page.
• Left menu item should be Liberty rather than Liberty Tools
• Clarify if both Maven and Gradle are supported

Page 33

• Can you have hover help over Start… to understand the difference between Start and Start… ? Discussed that this is a standard UI pattern to use ... to show configuration dialog will be displayed.

Page 34

• No Debug As in the MVP - Concerned that this pattern is expected? Revisit if Debug As is required for MVP.
• Can we have Debug As even if it requires a Run first.
• Clarify if the debug session is for the application, test, or server. Can you debug each of these?
• Follow up on this issue.

Page 38

• Should we use a different icon than the m2 or Gradle icon?

• Question: What happens if projects use the non-standard config locations? - Answer: This was handled in the general LSP UFO. There is a follow on issue to handle.

[scottkurz]

Another couple comments from after:

1. I'll paste another (internal) UFO comment was for the "Users configuring a Liberty server" user story:

I don't think the user story should say "Users". It should be specific like "Day 2 Operator" or "DevOps Developer" or whatever is appropriate (maybe more than one). Generic "Users" doesn't help understanding of when and why they're using the tools to configure the Liberty server.

2. Consider the "generic (e.g. Tomcat, generic sample like Baeldung, Jakarta, etc.) WAR. I'm saying it should be manually addable to "runAs Liberty" but not startable by default.

[frowe]

From the Friday 10/21/22 UFO review:
Slide 30
Consider adding a button to reset parameters to default
Rename "Main" tab
I asked about using the terms Start vs run ? Alasdair noted we’re not calling Start goal, we’re calling dev mode

Slide 38
Create icon for mvn instead of m2

Slide 40
Standard eclipse run config dialog is labeled JRE, but we require a JDK. Consider some way to indicate the need for JDK vs JRE

Slide 45
Typo "Lanaguage" should be "Language"

Slide 50
Update slide to mention config prefs

Slide 57:
I asked about the ability to upgrade (vs new install) of plugin. Scott to check on whether data updated to allow applying update to 04 release

Slide 62
Typo “issues” should be “issued”

Slide 63 typo “withing” should be “within”

General suggestion from Alasdair:
When in Tools and you open test results, it would be nice to open them in JUnit view

[scottkurz]

In slide 43, I wrote the mmod text the user must add as if it were the suggestion generated by Liberty Tools Eclipse.

[scottkurz]

I've addressed all comments with UFO updates and/or issues in our repo: https://github.com/OpenLiberty/liberty-tools-eclipse/issues

[yeekangc]

@scottkurz, please post link to latest UFO (with all feedback incorporated) and put in a "Design Approval Request" as soon as ready. Thanks.

[scottkurz]

Updated UFO at previous link: https://ibm.box.com/s/curdb0qg6su1jgtn4yhlf95m49hhkuu2

Let me highlight the updates from earlier rounds of review:

1. Added project name in Run Config - (eg. see slide 30) - The config is "scoped" to a project which determines the working directory when running and provides the key or link from dashboard management to a "session". If you use the new Run Config button we'll determine the project based on the active selection in the IDE workspace. So it at least needs to be displayed as you're working with the Run Config. I looked at making it editable, but getting the state/lifecycle correct is too much work in the near term.
2. Updated maven/gradle dashboard icons - (slide 26) - Not sure this is 100% final but essentially what we're looking at, a homegrown 'M' or 'G' icon of different colors
3. Design change to add Liberty nature to BOTH (Maven) top-level parent module AND server module - (slides 37,38) - This allows one to quickly import a typical Maven multi-mod project, right-click in Project Explorer, and Run/Debug As Liberty Start. It gives the user more choice, by providing one UI mapping to running from each of the parent/child directories. (Downside is there is more to visually look through and potentially wonder about what you should do). I can explain more as/if needed.
4. Maven/Gradle launch precedence - (slide 39)

• Added screenshot for preference.
• Added PATH env var as a 3rd/final resort.
• Added note clarifying that detecting the wrapper has a complication in Maven multi-module cases: the wrapper would typically be in the aggregate/parent dir which would not be found if running from the server module. This is one more reason to offer the choice of starting, working dir in 3. above.

5. Debug As - (slide 34) - This is a "single step" Debug. Liberty Tools will generate a "random" debug port, wait for it to appear in the generated server.env (by dev mode), and then launch a Remote Java Application debug configuration connecting to this port on localhost. User doesn't need to know port but it's visible in debug view. (Sorry, this is all text, would've been nicer to have some graphics.) Notably one thing missing now is an ability to launch this same 1-step debug from the dashboard. We'd have to consider that later.
6. Editor bindings - (slide 25) - Gave up on idea of binding the Lemminx XML LS function to the XML Editor. A user could just open an XML file with the Generic Text Editor and presumably create a binding from a generic XML extension like *.xml to this editor.

Besides that, let me make a few more notes:

1. Alasdair, in spite of your earlier (verbal) review comments, we left in the ability to do "Run As -> Liberty Stop", i..e the non-start commands (run tests, view report, etc.) , from the right-click Context menu. I think the additional convenience of not having to jump over to the dashboard to issue these commands outweighs any "conceptual clutter" or misalignment due to the fact that you're not "running Liberty". Not sure I convinced you so noting the change here.
2. I believe we have issues open for every UFO comment idea, that we wanted to consider pursuing after this release, e.g. Dashboard - include hover description clarifying the custom aspect of "Start..." vs "Start" liberty-tools-eclipse#209, Add button in Run Config to reset suggested command to generated default liberty-tools-eclipse#229
3. There might be some minor tweaks still in aligning the layout of the Run Config fields... but I think we're close enough that you could approve the design on the basis of this.

[scottkurz]

Additional update:

• clarified in slide 34 that Debug As integration won't work for multi-module Maven, and we will have to either guard/remove it in this case, or (more likely), provide a helpful error message if the user attempts it.

[NottyCode]

@scottkurz you are right that I'm not bought into having a "Run Stop" option in the UI, but as long as we can continue that discussion in the future I'm ok to approve despite not liking the current design.

[scottkurz]

(Deleted earlier template info and edited the original comment to include info based on the latest feature template)

[mbroz2]

@scottkurz the above looks to be using an extremely outdated template from somewhere. Please update using the latest feature template: https://github.com/OpenLiberty/open-liberty/issues/new?assignees=&labels=Epic&template=feature.md&title=Open+Liberty+Feature+Template

[scottkurz]

@mbroz2 - this isn't a runtime feature but a devex one. We've been talking about coming up with a DevEx template but it seemed like this old template was just as good to work from .

[mbroz2]

@scottkurz I would still recommend basing any new templates off of the latest version of the open-liberty feature template (and updating the one in this issue). Many things you have above are incorrect... for example, various focals like a11y and even WDT.

[scottkurz]

Closing as complete

[malincoln]

@scottkurz @yeekangc this feature was closed but is missing the other focal approvals.

[scottkurz]

@malincoln For these non-runtime features, like this Eclipse tooling feature, we haven't generally been adding the full set of focal approvals or checking off the full template's checklist. We have in this case followed a subset of the process and done more than just the UFO by adding the SVT and ID approvals.