Add support for a CLI

[ivargrimstad]

Create a CLI tool that is based on the archetypes to simplify the developer experience.

• Generate
• Start/Stop

[ivargrimstad]

Consider picocli and distribution with SDK Man

[m-reza-rahman]

The current consensus is that this is a low priority item to be implemented after the more important priorities are addressed. Concise input from key community members can be found here: https://docs.google.com/spreadsheets/d/1bthiYVjX_UK7Xp2qQmq93awPwVhVCDnprGdzeMtv_ow/edit?usp=sharing. A discussion thread on the mailing list can be found here: https://www.eclipse.org/lists/starter-dev/msg00188.html.

[m-reza-rahman]

Personally I think we should invest our limited time to move forward other things first. For me a CLI could be considered later mostly to better support Gradle in the command line (e.g. invoking 'gradle init' behind the scenes on a generated Maven project). As such, even Gradle support itself is low priority. A limited set of hopefully self-explanatory Maven Archetypes should be easy enough to use both from the command line and IDE. A CLI is yet another thing for us to maintain/document and yet another thing for the user to install/configure/learn about after all. We should go this route when there is a clearer value proposition. Right now is definitely way too early.

[rcuprak]

I would really like to see a CLI similar to what is available for Angular (https://angular.io/cli). I primarily use the command line as opposed to a website. In my mind, this CLI would be more than just a simple utility to bootstrap a project. It would be nice if you could use it to "enable" features - such as add JPA, create an JPA entity, create a new restful web service, etc. It would also be beneficial if it could upgrade a project to a new version of Jakarta EE. In terms of installing the tool, have it deployed via a package manager (and updated accordingly) at least for Linux/Mac. I install practically all of my tools on MacOS using Brew (https://brew.sh). I think past projects, such as JBoss Forge, were too tied to an IDE. What trips people up when using Jakarta EE, is post-project creation steps. Try guiding someone through enabling JPA or standing-up their first JAX-RS service. Depending upon what they Google, they can end up writing code like it is 2009.

[kito99]

I'd like to add that we should consider using https://jreleaser.org/ for whatever we come up with. It seems like a great way to promote the project as well.

[kito99]

That being said, let's get the core stuff working first. No point in working on a CLI until you can at least use a decent web UI and get a ZIP file.

[m-reza-rahman]

I was honestly a fan of both Forge and seam-gen. However, looking at the scope, investment level, and goals of those efforts, I think a "Jakarta CLI" is a separate project to which this may or may not be a sub-component at some point. I think Spring Boot got it right by focusing simply on the very early getting started experience instead of full blown code generation akin to what a very feature rich IDE plugin for Jakarta EE would do.