Integrated set of Liberty tools for developers downloadable from VS Code's marketplace

[yeekangc]

Enable developers that use VS Code 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 using APIs like Jakarta EE and MicroProfile.

Solution involves creating a VS Code extension for Liberty that enables developers to easily create and develop cloud-native Java applications with Liberty in VS Code.

Extension 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

When ready, add links to the Upcoming Feature Overview document as well as Feature Test Summary and blog post issues:

• UFO: https://ibm.box.com/s/boj3yxdlfst149ncpt3ezezeq5st7bq8
• FTS: Feature Test Summary - Liberty Tools VS Code - 23.0.6 liberty-tools-vscode#311
• Beta Blog Post: Blog post for Liberty Tools' Dec 2022 refresh blogs#2796
• Blog Post: Blog post: Updates for Liberty Tools and Liberty build plugins blogs#3184

---

List of Steps to complete or get approvals / sign-offs for Onboarding to the Liberty release (GM date)

Instructions:

• Do the actions below and mark them complete in the checklist when they are done.
• Make sure all feature readiness approvers put the appropriate tag on the epic to indicate their approval.

Design

Before Development Starts or 8 weeks before Onboarding

• POC Design / UFO Review Scheduled (David Chang) or N/A.
• POC Design / UFO Reviewed (Feature Owner) or N/A.
• Complete any follow-ons from the POC Review.
• Design / UFO Approval (Alasdair Nottingham) or N/A.
• [N/A] No Design / No UFO Approval (Arthur De Magalhaes - cloud / Alasdair Nottingham - server) or N/A.
• SVT Requirements identified. (Epic owner / Feature owner with SVT focal point) SVT epic
• ID Requirements identified. (Epic owner / Feature owner with ID focal point) Doc issue
• Create a child task of this epic entitled "FAT Approval Test Summary". Add the link in above.

Beta

If your feature, or portions of it, are going to be included in a beta
Before Onboarding the beta

• [N/A] Beta Fence the functionality (kind=beta, ibm:beta, ProductInfo.getBetaEdition())

1 week before beta GA

• [N/A] Create, populate, and link to the Beta blog post issue

Legal

3 weeks before Onboarding

• Identify all open source libraries that are changing or are new. Work with Legal Release Services (Cass Tucker or Release PM) to get open source cleared and approved. Or N/A. (Epic Owner). New or changed open source impacts license and Certificate of Originality. ==> 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

3 weeks before Onboarding

• [N/A] All new or changed PII messages are checked into the integration branch, before the last translation shipment out. (Epic Owner) ==> N/A Our initial release will have no translation.

Feature Complete

2 weeks before Onboarding

• Implementation complete. (Epic owner / Feature owner)
• All function tests complete. Ready for FAT Approval. (Epic owner / Feature owner)
• Review all known issues for Stop Ship. (Epic owner / Feature owner / PM)

Focal Point Approvals

2 to 1 week before Onboarding

You MUST have the Design Approved or No Design Approved label before requesting focal point approvals.

All features (both "Design Approved" and "No Design Approved")

• [N/A] FAT - (Adam Yoho, Martin Holder, or Dave Waddling). SOE FATS are running successfully or N/A . Approver adds label focalApproved:fat to the Epic in Github.
• Demo - (Tom Evans or Chuck Bridgham). Demo is scheduled for an upcoming EOI. Approver adds label focalApproved:demo to the Epic in Github. ==> Scheduled for 11/29
• [N/A] Globalization (Sam Wong - Liberty / Simy Cheeran - tWAS). Translation is complete or N/A. TVT - complete or N/A. Approver adds label focalApproved:globalization to the Epic in Github.

"Design Approved" features

• [N/A] Accessibility - (Steven Zvonek). Accessibility testing is complete or N/A. Approver adds label focalApproved:accessibility to the Epic in Github.
• ID - (Kareen Deen). Documentation work is complete or N/A . Approver adds label focalApproved:id to the Epic in Github.
• [N/A] Performance - (Jared Anderson). Performance testing is complete with no high severity defects or N/A . Approver adds label focalApproved:performance to the Epic in Github.
• [N/A] Serviceability - (Don Bourne). Serviceability has been addressed. ==> This will be supported through the OSS community.
• [N/A] STE - (Swati Kasundra). STE chart deck is complete or N/A . Approver adds label focalApproved:ste to the Epic in Github.
• SVT - (Brian Hanczaryk - APS). SVT is complete or N/A . Approver adds label focalApproved:svt to the Epic in Github.

Ready for GA

1 week before Onboarding

• No Stop Ship issues for the feature. (Epic owner / Feature owner / Release PM)
• Ship Readiness Review and Release Notes completed (Epic owner / Feature owner / Release PM)
• Github Epic and Epic's issues are closed / complete. All PRs are committed to the master branch. (Epic owner / Feature owner / Backlog Subtribe PM)

1 week before GA

• Create, populate, and link to the Blog post issue

Other deliverbles

• OL Guides - (Yee-Kang Chang). Assessment for OL Guides is complete or N/A.
• [N/A] WDT - (Leonard Theivendra). WDT work complete or N/A.
• Blog - (Laura Cowen) Blog article writeup (Epic owner / Feature owner / Laura Cowen)

[yeekangc]

@kathrynkodama is working on first draft of the UFO.

[cthigh]

UFO review on Monday Oct 3, 2022.
@kathrynkodama presented
@cthigh moderated
Approximately 37 participants

Notes:
Page 9

Tom asked how do the tools determine whether to restart the server? devMode handles server restart based on the file being edit.

Chuck asked if there is a connection to logging in console view? Yes covered later

Page 12

Tom - What sorts of completion are provided for properties? List of supported keys defined in the Liberty Language Server UFO. Found about 20 properties in the Liberty documents.

Side conversation on properties in webex chat:
from CHERYL KING (IBM) to Everyone: 10:17 AM
This is the link to the Liberty Config Language Server UFO if anyone wants to see the list of documented bootstrap and server.env properties we provide completion for.
https://ibm.box.com/s/pfw3l83ny1gy3k11x1611uhfbxnyrta1
from CHERYL KING (IBM) to Everyone: 10:18 AM
Slides 29-32 for the list of props in that UFO.
from Michal Broz (IBM) to Everyone: 10:19 AM
Cheryl have you talked with docs team regarding formally documenting these on a single docs page?
from Michal Broz (IBM) to Everyone: 10:19 AM
if not, I think it's worth having that conversation in #openliberty-docs
from Thomas Watson (IBM) to Everyone: 10:21 AM
I think we would want an automated way to specify that somehow. Perhaps as an annotation on the class that reads the system property? And that would help in generating the doc?
from Yee Kang Chang (IBM) to Everyone: 10:22 AM
Right, that is our ultimate goal i.e. that we don't have to manually process for the tools (Liberty Config LS). Then, that's an eventual goal and not what we have currently scoped for the MVP.
from Yee Kang Chang (IBM) to Everyone: 10:22 AM
As Cheryl noted, we have filed an issue for this so we can use that to discuss and work out a solution.
from CHERYL KING (IBM) to Everyone: 10:23 AM
@michal They are documented in a couple different pages in the Liberty docs. Are you suggesting those docs need to be reorganized? Or that we need an additional page specific to Liberty Tools that documents those properties? Or links to them?
from CHERYL KING (IBM) to Everyone: 10:24 AM
Here is the open issue for following up on the properties. Feel free to add your thoughts there. OpenLiberty/liberty-language-server#76
from Michal Broz (IBM) to Everyone: 10:24 AM
I'm suggesting we have a discussion regarding what is the best approach for documenting these, whether that's already how it is, or a different approach.
from Michal Broz (IBM) to Everyone: 10:24 AM
ah, great

P 11

Michal asked whether the tools can help get the liberty-maven|gradle-plugin configured where it is not configured since it is required?


Stretch goal to help configure LMP.

Can we make them more aware of LMP as a minimum?

P 21 - multi-module maven projects

Dana: Will Start… supply some attributes or will user need to provide? User to provide.

Scott - Design choice to not look every time for which project is the aggregator. When the entire maven project is run, then they will get more information.

Might be good to pre-populate the Start… panel.

P 23
Will Start… get repopulated with the last commands entered? Kathryn to clarify.

P 27
Rumana - What is the location for user-shared-config (usr/shared/config)? Anywhere under source tool should recognize, but user needs to do something to get it to copy.

Scott - Add note on what is possible for VS code. Different view for displaying source versus target files.

Jared asked about the “Liberty schema” - a schema exists but it is generally not set. Liberty Language Server calls the schema gen.

P 30 - One install, but will pull in dependencies automatically.

P 36

YK clarified that multi-module support is a stretch goal to handle in the initial release. Add note - this also affects SVT (p43)

P 32

Chuck Bridgham - Can we make dev tools more prominent on openliberty.io?
YK - Update current downloads page for initial release.
Longer term want to land developers on the tools more easily.
Docs have a conversation going

[kathrynkodama]

@NottyCode I have updated the design based on the comments above from the POC Forum. https://ibm.box.com/s/boj3yxdlfst149ncpt3ezezeq5st7bq8

Slide 20 & 43:

• Added a note to clarify multi module support is a stretch goal for GA

Slide 27 Liberty Config LS Features:

• Removed the reference to the schema location attribute. This clarifies that Liberty specific language features for server.xml files will be delivered when a server.xml file has a root element "server" and exists in "src/main/liberty/config", "configDropins/overrides", "configDropins/defaults", "usr/shared/config", "usr/servers" directory.
• As far as we know there is no way built-in capability of VS Code to differentiate between src and target files.

Slide 29 Jakarta EE LS:

• Clarified the granularity of API detection in LSP4Jakarta: classpath detection is per Jakarta EE API, eg. if jakarta.servlet is found on the project's classpath, completion items and diagnostics will be delivered for jakarta.servlet API usage.

Slide 30 End User Overview:

• Updated to say Liberty Config Language Server rather than calling out the individual files supported by the Liberty Config Language Server.

Slide 32 Communication:

• Added the openliberty.io downloads page and documentation.

[kathrynkodama]

Updated slides 17 and 23 to clarify: The "Start..." command allows users to edit the entire Liberty dev command and that users will be able to select previously run "Start..." commands for easy re-run access.

[kathrynkodama]

Updated the UFO (https://ibm.box.com/s/boj3yxdlfst149ncpt3ezezeq5st7bq8 ) with the following key changes:

• Reordered feature design slides to align better with Eclipse (Integrated set of Liberty tools for developers downloadable from Eclipse IDE's marketplace #10352) and IntelliJ designs (Integrated set of Liberty tools for developers downloadable from IntelliJ IDEA's marketplace #14957)
• Slides 16 & 17: Added the Prereqs and Install slides
• Slides 18 & 20: The "Start..." action will not append the -f build-file parameter. The working directory will be set to the Liberty project's root directory.
• Slide 20: Added the “Attach debugger” action
• Slide 22: Added the “Debug Configuration” details

[kathrynkodama]

@NottyCode please review the updated design. Thank you

[kathrynkodama]

@NottyCode Here is a more detailed breakdown of how each socialization comment has been addressed in the design document. I've also made a few minor updates to the design to make these items clearer. https://ibm.box.com/s/boj3yxdlfst149ncpt3ezezeq5st7bq8

Notes: Page 9

Tom asked how do the tools determine whether to restart the server? devMode handles server restart based on the file being edit.

Chuck asked if there is a connection to logging in console view? Yes covered later

Referring to "High Level User Stories" (slide 9). No UFO update required, question refers to dev mode behaviour outside of the scope of this feature. Dev mode will handle server restart, not Liberty Tools for VS Code. Logging is covered on "Serviceability" (slide 49), standard output and error of Liberty Tools for VS Code will be written to the VS Code Output Tab and Developer Tools Console.

Page 12

Tom - What sorts of completion are provided for properties? List of supported keys defined in the Liberty Language Server UFO. Found about 20 properties in the Liberty documents.

Side conversation on properties in webex chat: from CHERYL KING (IBM) to Everyone: 10:17 AM This is the link to the Liberty Config Language Server UFO if anyone wants to see the list of documented bootstrap and server.env properties we provide completion for. https://ibm.box.com/s/pfw3l83ny1gy3k11x1611uhfbxnyrta1 from CHERYL KING (IBM) to Everyone: 10:18 AM Slides 29-32 for the list of props in that UFO.

Referring to "As-Is: Liberty Configuration" (slide 12). No updates to the UFO needed here. As Cheryl covered in the chat, this is documented in the Liberty Config Language Server UFO.

P 11

Michal asked whether the tools can help get the liberty-maven|gradle-plugin configured where it is not configured since it is required?

 Stretch goal to help configure LMP.

Can we make them more aware of LMP as a minimum?

Referring to "To-Be: Running Dev Mode" (slide 11). Updated "As-Is/To-Be: Running dev mode" (slides 10 & 11) to clarify that users will have to configure the Liberty Maven/Gradle plugin in the build file if it is not already present. Issue OpenLiberty/liberty-tools-vscode#156 was opened for an enhancement to the extension to help users configure the Liberty build plugins (post GA).

P 21 - multi-module maven projects

Dana: Will Start… supply some attributes or will user need to provide? User to provide.

Scott - Design choice to not look every time for which project is the aggregator. When the entire maven project is run, then they will get more information.

Might be good to pre-populate the Start… panel.

Referring to "Feature Design: Multi Module Maven projects" (now slide 27). Slide "Feature Design: Start vs Start..." (slide 19) indicates that Start... panel will be pre-populated. We will pre-populate "Start..." with our "best guess" for multi module project structures. User will have to provide additional attributes (eg. dev mode params like -DhotTests or a specific Maven profile).

P 23 Will Start… get repopulated with the last commands entered? Kathryn to clarify.

Updated "Feature Design: Start vs Start..." (slide 19) to clarify that on subsequent "Start..." runs, there will be an additional step where users will be able to select from previously run "Start..." commands for easy re-run access.

P 27 Rumana - What is the location for user-shared-config (usr/shared/config)? Anywhere under source tool should recognize, but user needs to do something to get it to copy.

Scott - Add note on what is possible for VS code. Different view for displaying source versus target files.

Jared asked about the “Liberty schema” - a schema exists but it is generally not set. Liberty Language Server calls the schema gen.

Referring to "Feature Design: Liberty Config LS Features" (now slide 29). Location is in the target/build directories but the Liberty Config Language Server will be handling this logic and will look for file patterns matching "usr/shared/config". No UFO update required, but noting that there is not a different view in VS Code for displaying source vs target files.

P 30 - One install, but will pull in dependencies automatically.

Referring to "End User Overview: Liberty Tools" (now slide 32). No UFO update required. There will be one install of the Liberty Tools for VS Code extension, which will include all necessary dependencies. Any dependent VS Code extensions, ie. Tools for MicroProfile will be installed automatically.

P 36

YK clarified that multi-module support is a stretch goal to handle in the initial release. Add note - this also affects SVT (p43)

Updated "Feature Design: Multi Module Maven projects" (now slide 26) to clarify that this is a stretch goal for GA. Also called this out on "System Test Impact" (slide 45).

P 32

Chuck Bridgham - Can we make dev tools more prominent on openliberty.io? YK - Update current downloads page for initial release. Longer term want to land developers on the tools more easily. Docs have a conversation going

Referring to "Communication" (now slide 34). Updated to indicate that the openliberty.io page and documentation will be updated to mention Liberty Tools for VS Code.

[yeekangc]

Thank you, Kathryn, Alasdair!