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):
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.
Current annotation model works like:
@ShellComponentis needed to introduce wrapping class into context asBean.StandardMethodTargetRegistrarin a standard package queries@ShellComponentbeans from a context and scans@ShellMethodmethods and manually createsCommandRegistrationinstances and register those intoCommandCatalog.@ShellComponentis a@Componentthis wrapping class is then available as an object instance to target command invocation via reflection.Ultimate plan is to deprecate whole
spring-shell-standardmodule and create a full modern annotation system replacement which aligns better withCommandRegistrationsystem 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
@ShellComponentand align new annotation system with concepts from a modern boot/framework:In no particular order new annotations could look like(draft of some ideas and more detailed in annotation specific issues):
Command
@Commandon 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
@Optionin a method parameter level to add metadata for command options.EnableCommand
@EnableCommandannotation would be similar to boot's@ConfigurationPropertiesdefining class targets.CommandScan
@CommandScanannotation would be similar to boot's@ConfigurationPropertiesScandefining classpath scanning targets.ExitCode
@ExitCodein a method level with@ExceptionResolverwould instruct non-interactive command what to return in case of an error.