- In `CommandRegistration` add `ResolvableType` for `OptionSpec` giving
more spesific handling of a type.
- In `CommandParser` handle source and target types so that we
have generics with `List`, `Set` and arrays working better.
- In `HandlerMethodArgumentResolver` add better handling for
`ConversionService` for generic types.
- In `StandardMethodTargetRegistrar` add better types via `ResolvableType`
now that `CommandRegistration` support it.
- In `OptionConversionCommands` remove converter from `String` to `Set` as
now things should work as is if generic in a `Set` has a converter.
- Fixes#694
- While option should be defined i.e. using "--arg", discover
prefix from ShellMethod#prefix and use that if just "arg"
is defined.
- Backport #575
- Fixes#577
- In a case where arg is given as boolean and with plain
@ShellOption (user doesn't define defaults), configure
arg not to be mandatory and with default value false.
- This brings this spesific case more close how it behave
in older shell version.
- Having `@ShellOption boolean arg1` it now works as:
my-shell:>e2e reg default-value-boolean3
Hello false
my-shell:>e2e reg default-value-boolean3 --arg1
Hello true
my-shell:>e2e reg default-value-boolean3 --arg1 false
Hello false
my-shell:>e2e reg default-value-boolean3 --arg1 true
Hello true
- Fixes#461
- For annotated methods with arguments, change default arity
to zero with booleans and one everything else regardless
if @ShellOption is defined or not.
- OptionArity.ZERO_OR_ONE had wrong upperbound value, change
from MAX to 1.
- These modification should take us a bit closer to old
shell functionality and what ShellOption documents for arity.
- For old functionality I'm referring to method
`add(int a, int b)` and/or having @ShellOption and/or without
arity setting.
- Fixes#446
- Use same interface type in a generic interactive completions
in a method level and option value level.
- Change CompletionResolver to have same function signature
as with options and use CompletionContext to keep
relevant information.
- Fixes#449
- This is a re-implementation of a interactive completion
with breaking changes as it moves away from a direct use
of a MethodParameter in favour of a CommandRegistration
and its option definitions.
- Fixes#449
- Change help command output to get templated using
model classes.
- Remove things around ParameterDescription as those are
replaced with template classes.
- Fixes for native configs.
- For now availability and aliases are removed from
help to get back in better form.
- Aliases has been partly introduced to structure.
- Fixes#422
- Focus of these changes are to introduce a new command system based on
real registrations (new way) instead of continuously (old way) resolve
methods and its parameters via reflection.
- There's a lot of changes as this resolution via reflection had its
hooks almost everywhere and thus most changes are just refactorings.
- Order to understand real changes I'd start to look classes under
`org.springframework.shell.command` package as it defines new registration,
catalog and parser classes. Also samples contain new classes to demonstrate
new functionality.
- Fixes#380
- Add new styling system which works around concept that
you use tags to request jline styles where tags comes
from an activated theme.
- There is a default theme with options to add custom
ones and change it via property.
- Add templating system which uses antlr stringtemplate which
allows to write output with a template instead of manually
crafting code.
- Add version command which integrates to Boot's BuildProperties
and GitProperties. Only version field is visible on default
and others can be enabled/disable via properties.
- Fixes#352
- Fixes#353
- Add new ShellContext concept which now is just a way
to stash info about interaction mode where ShellRunner
can update supported mode.
- ShellMethod has a new field interactionMode which user
can use to define commands between interactive/non-interactive
modes which then prevents CommandRegistry to show
commands at runtime.
- Fixes#345
- Add basic support of defining a command `completion bash` which
outputs a generic bash script which can be used in a user environment.
- Idea for completion is copied from go's cobra library what comes for
a bash dance itself.
- Goes through command registry, builds a model for command structure
and uses antlr st4 for templating bash.
- Should give foundation to create other completions just like in cobra.
- Currently as we don't know a root-command in a generic way, option
`spring.shell.command.completion.root-command` is required user to set.
- Fixes#343
- Lot of rework to move better model to work around bean cycles
- Remove use of @Lazy
- Move StandardAPIAutoConfiguration to autoconfig package
- Remove some of a direct ObjectProvider use in constructors
- Adds spring-native support with most of a things working out of a box
- Relates #324
- Relates #329
- Relates #323
- Migrate tests to junit5 and assertj as those
are on a classpath automatically.
- Temporarily use spring.main.allow-circular-references=true
to allow time for fixes to remove cycles.
Handle exit as a dedicated case (prevents eg 'exit' commands in scripts to make script quit)
Add an example of custom ApplicationRunner
Fixes#187Fixes#183
Decouple ApplicationRunners
Make ThrowableResultHandler behave differently in non-interactive mode
