Support @Spec annotation to inject CommandSpec into command implementation

[remkop]

See for example the auto-help use case: a command help subcommand command should print help for the specified subcommand of the parent command. This means it needs to obtain a subcommand CommandLine or CommandSpec object from the parent command. The @ParentCommand annotation does not work because it injects the user-defined command object, not the picocli class.

Another use cases is custom commands that need to know exactly which options were actually specified on the command line. This could be accomplished by injecting the ParseResult (#257).

A generic @Inject annotation is generic and flexible enough to allow future extensions, while at the same time the meaning is intuitively clear to many users because of its similarity to JSR-330 (javax.inject.Inject).

[kakawait]

@remkop Nice addition. First at all, I didn't try why I will speak about, is just theoretical analysis.

But currently on picocli-spring-boot-starter commands use to be a Spring component/bean. And Spring in addition to @Autowired annotation is also aware of @Inject annotation for DI.

But CommandSpec, CommandLine and ParseResult will not be registered on Spring context (no sense to be registered), so I'm afraid that Spring will complain about:

No bean of type ... found

What do you think about?

How we can solve that? I think with alternative and more old school way to inject that component for example by implementing a picocli interface which defined 3 setters (or whatever) that will be used by picocli to inject that components. A bit like what I did on picocli-spring-boot-starter

https://github.com/kakawait/picocli-spring-boot-starter/blob/master/picocli-spring-boot-autoconfigure/src/main/java/com/kakawait/spring/boot/picocli/autoconfigure/PicocliCommand.java#L53

https://github.com/kakawait/picocli-spring-boot-starter/blob/master/picocli-spring-boot-autoconfigure/src/main/java/com/kakawait/spring/boot/picocli/autoconfigure/PicocliCommandLineRunner.java#L59

[remkop]

I think Spring is looking for the javax.inject.Inject annotation, while this is a custom picocli.CommandLine.Inject annotation. I don't think Spring will see the picocli annotation.

If a class uses both the picocli and the javax @Inject annotation, then at least one of them needs to be annotated with the fully qualified class name.

[kakawait]

Lol my bad I read to quickly I though it was javax.inject.Inject. Sorry

[remkop]

No worries. Thanks for checking!

[kakawait]

Are you not afraid that people will have confusion between both annotations, and some of them will still import javax.inject.Inject instead of picocli.CommandLine.Inject

[remkop]

Yes there is some risk there. The benefits are no external dependency and a name that is intuitively obvious in what it does. So there’s a trade-off. I’ll add a note in the documentation. Thanks for pointing this out.

[remkop]

It turns out that the custom HelpCommand use case also required that the Help.Ansi object and the output PrintStream are injected... It’s becoming a bit too “magical”...

Reconsidering defining a IHelpCommand interface instead.

[remkop]

I introduced interface picocli.CommandLine.IHelpCommandInitializable to implement the custom help command use case.

I reverted commits 2cb8d66 and a781f80 to remove the @Inject functionality for now, until another use cases comes up.

[fcorneli]

I'm also looking for a way to "help subcommand" properly.

[remkop]

@fcorneli Can you try with current master?

[remkop]

Picocli 3.0 (in master) has a built-in help command that can give help on a specified subcommand or on the preceding command.

See https://github.com/remkop/picocli/wiki/Manual-(3.0.0-SNAPSHOT)#built-in-help-subcommand

[remkop]

FYI: I ran into a use case that requires access to the picocli command model from the application, so this will be available from picocli 3.2.

The use case has to do with JLine completion candidates (#393, also in v3.2).
Some completion candidates need to be looked up dynamically from some resource that is only available at runtime. Access to the CommandSpec is needed to update the option's ArgSpec.completionCandidates after the lookup.