-
Notifications
You must be signed in to change notification settings - Fork 392
Closed
Description
Hi everyone!
In the last week I've spent a lot of time evaluating frameworks with CLI capabilities.
I'd like to summarize here my current understanding of the JVM ecosystem and why I did not chose Spring Shell.
-
Which frameworks did I evaluate?
- Micronaut (Picocli)
- Quarkus (Picocli)
- Spring Shell
-
What was I looking for?
- easy development workflow.
I'm developing a command, I want to press a button in the IDE and debug it (with an active context) ❌ - easy testing, with an out-of-the-box testing framework for the CLI ❌
- small native size (in GraalVM terms obviously) ❌
Bonus:
- out-of-the-box interactive shell capability ✔️
- multi-step command flow ✔️🆘
- easy development workflow.
-
What did I pick in the end?
Quarkus -
Why?
- built-in UPX compression step
- faster native image start-up
- cool command testing tools (
@Launchannotation,LaunchResultparameter)
Spring Shell related:
- the command flow is awesome, but it's mostly broken on Windows. I found myself getting mad at the prompt when typing.
Also, it doesn't work when starting the application through an IntelliJ IDEA (Ultimate) run configuration. - the command as method is a nice idea, but it's impractical with a lot of parameters, each with its own annotation spawning multiple lines
- the documentation is still a bit a lacking.
For Quarkus and Micronaut I can just navigate to the Picocli guide and that's it, as the framework layer is small.
For Spring Shell I found myself looking at random blog posts or StackOverflow questions
All in all, you are doing an amazing job here, and I think I'll switch to Spring Shell in the future.
I'd just like to see more love for Windows (like, I inited a project, built the JAR straight away, and got an exception running it) and testing.
I'll keep this issue updated as I progress with my CLI project capabilities.
rainboyan
Metadata
Metadata
Assignees
Labels
No labels