New Annotation Model

[jvalkeal]

Current annotation model works like:

• @ShellComponent is needed to introduce wrapping class into context as Bean.
• StandardMethodTargetRegistrar in a standard package queries @ShellComponent beans from a context and scans @ShellMethod methods and manually creates CommandRegistration instances and register those into CommandCatalog.
• As @ShellComponent is a @Component this wrapping class is then available as an object instance to target command invocation via reflection.

Ultimate plan is to deprecate whole spring-shell-standard module and create a full modern annotation system replacement which aligns better with CommandRegistration system and its new features(some only available if registration is created as a bean) which cannot be used with old annotations.

We want to move away from all automatic ways what happens with @ShellComponent and align new annotation system with concepts from a modern boot/framework:

• Be more restrictive what comes for a classpath scanning.
• Allow to define command targets using modern annotation and class structure boot user are familiar with.

In no particular order new annotations could look like(draft of some ideas and more detailed in annotation specific issues):

• Reorganise e2e samples #642
• @CommandAvailability Annotation #663
• @Command Annotation #638
• @Option Annotation #639
• @EnableCommand Annotation #640
• @CommandScan Annotation #641
• Document feature

Command

@Command on a class level would be used to mark it as target for finding commands and on a method level marking it as target for command logic. Annotation on a class level would be used to provide some defaults for methods in that particular class.

Option

• @Option in a method parameter level to add metadata for command options.

EnableCommand

• @EnableCommand annotation would be similar to boot's @ConfigurationProperties defining class targets.
• For example, use it as @EnableCommand({ MyCommands1.class, MyCommands2.class} )

CommandScan

• @CommandScan annotation would be similar to boot's @ConfigurationPropertiesScan defining classpath scanning targets.
• For example, use it as @CommandScan(basePackages = "org.example.commands")

ExitCode

• @ExitCode in a method level with @ExceptionResolver would instruct non-interactive command what to return in case of an error.

[jvalkeal]

Marking closed and expecting further issue in a separate tickes.