quarkus: Add support for applications which immediately exit

Being able to easily create Quarkus CLIs might be a good way of keeping people for using Go for such tools

I’m almost finished with my current task, and this one will be next.

Excited to see that there already is discussion on how an integration with picocli could work. Actually, i am awaiting the quarkus cli-support to move a micronautfw CLI application to a more standard platform. Micronaut has helped me to get some initial prototype up an running but before sharing the tool with my coworkers or extendeding on it, i want to see it moved to a standard like Java/JakartaEE. I will keep monitoring this closely…

Would there be any interest in cooperation with the picocli project? Picocli has:

• GraalVM native image support (see the picocli-codegen annotation processor)
• an intuitive API with annotations for options and positional parameters, invoked with one line of code; all an application needs to do is implement Runnable/Callable and put the business logic there (see example).
• usage help with ANSI colors
• TAB autocompletion
• subcommands (to any level)
• advanced parsing features like repeating composite argument groups, e.g. <cmd> ([-a=<a> -b=<b> -c=<c>] (-x | -y | -z))...
• extensive documentation (https://picocli.info)
• is actively maintained

I’ve been on vacation for a few weeks and just got back. I intend to bring #2866 up to date with all the concerns addressed ASAP.

Just as an update, I’ve been working on a design proposal for this which I hope to have ready sometime next week.

I’m interested in helping with this… been in the go “dark” side for a while and have to admit that creating CLIs with things like cobra is quite pleasant and fast compared to what I’ve seen in the Java world last time I looked.

How can I help? Any stuff I could do to make it happen faster? Can’t wait to see picocli+Quarkus!!!

No but I could spitball a few concepts to see what sticks.

The simplest to implement would be to have a user-provided implementation of the proposed ExecutionHandler interface, which would look something like this:

@ApplicationScoped // I assume we'll be able to do it this way...
public class MyMainClass implements ExecutionHandler {
    @Override
    public int run(ExecutionChain chain, ExecutionContext ctxt) throws Exception {
        List<String> args = ctxt.getArgumentsAsList();
        boolean ok;
        // do whatever with args, and decide if everything is OK
        // ultimately populate 'ok'
        return ok ? 0 : 1
    }
}

Another option would be to provide a “smart” annotation that could be applied to exactly one method on one application-scoped bean:

public class BeanClass {
    // ...
    @MainMethod
    public int myMain(List<String> args) {
        // we could allow int or void returns, args as array or list (or none), etc.
        doStuff();
        return 0; // ok
    }
}

Share other ideas if you have them!

@remkop sure, I’d need to take another look at picocli, first, though as it’s been a while! 😄

I prefer the second option, it seems more clear and coherent with an usual main class. Also, exposing xecutionChain and ExecutionContext is making it too complex. People with basic knowledge of Java may be confused, while there is nothing confusing with @MainMethod and the List<String> args.

Any progress or timelines on this? I am highly interested as well.

Is there any example code somewhere of what this would look like?