Closed maxandersen closed 2 years ago
duplicates #418
@anyone Was there any progress been made? Thanks!
@maxandersen so how much will we want to do in the next 3-6 months and how different is it from "command mode"?
@dodalovic @stuartwdouglas has done some ground work named command mode. I'm not sure what would be required to be a proper CLI exposed model. Reusing Aesh or picocli was floated.
Stuart does need feedback on the command mode at the moment.
Sure, what’s needed?
On Tue 24. Mar 2020 at 15:01, Emmanuel Bernard notifications@github.com wrote:
@dodalovic https://github.com/dodalovic @stuartwdouglas https://github.com/stuartwdouglas has done some ground work named command mode. I'm not sure what would be required to be a proper CLI exposed model. Reusing Aesh or picocli was floated.
Stuart does need feedback on the command mode at the moment.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/quarkusio/quarkus/issues/6026#issuecomment-603255871, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQQILJNQRRC3JUH6A43GI3RJC4J7ANCNFSM4JYAX6LQ .
-- Sent from Gmail mobile
There you go, check this PR https://github.com/quarkusio/quarkus/pull/7681 Feedback is good, also building it and testing it would be great feedback for Stuart.
command mode is what enables us to actually use quarkus to write the cli which I think we should (drink own champagne and pet the dog etc.).
about next 3-6 months - let me review the others outstanding.
I can't wait for Quarkus to get cli support !! I expected things to be much better in this area.
We need to discuss if the CLI should have introspection capabilities and do a JBoss Forge like class creation / augmentation based on the existing user model. This would make it non native and might be a blocker compared to the advantage of going native.
Any sort of dynamic command based support will prevent native mode from being viable (barring some kind of 'mixed mode', where we use the native process to bootstrap the CLI and do simple tasks, and delegate to a JVM for any kind of dynamic support).
FYI: The Maven/Gradle wrappers are now included by default using codestarts (not added by maven) making the generation of projects consistant across our different tooling.
Any updates on this issue? Should it be moved to 1.9?
Yeah it was merged for 1.9: https://github.com/quarkusio/quarkus/pull/11450
closing this as cli is there and delivered. lets have more dedicated issues for future improvements.
Description
start with "Quarkus CLI" i.e. qtl or qu focused on giving an easy getting started experience; remove or at least make mvn/gradle commands optional/secondary and from there derive a CLI framework.
Analysis
short name:
qs
as in ( Q uarku S ) aliased or linked toquarkus
distribution: initally a zip with .cmd/.bat + shell script + uber.jar'ed Quarkus command mode app. Eventually produce binaries for windows, osx, linux; but always have plain jar option available.
suggested commands:
qs create
orqs init
as alternative to mvn dependent project creation and do add/list extensionsdeploy
target for doing the "right" thing to deploy without having to remember all the flags :)build
to call into mvn, gradle or buildless option.update/migrate
tasks to ask to update to specific version and get info/docs on what changed.Epic items
(this section is auto-generated - manual edits will get lost)