Update dependency info.picocli:picocli to v4.6.1

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
info.picocli:picocli (source)	4.4.0 -> 4.6.1

---

Release Notes

remkop/picocli

v4.6.1

The picocli community is pleased to announce picocli 4.6.1.

This release fixes a problem with dependency scope in the following sub-modules:

• picocli-codegen
• picocli-groovy
• picocli-shell-jline2
• picocli-shell-jline3
• picocli-spring-boot-starter

The problem was that these modules contained dependencies that were declared to have implementation scope instead of api scope.
However, these were transitive dependencies, and necessary to compile any project that uses the above picocli modules.

In this release, transitive dependencies are declared with api scope in the above modules.

Special thanks to Sualeh Fatehi, Dejan Stojadinović and Semyon Levin for the quick community feedback, pull request and reviews!

This is the seventy-sixth public release.
Picocli follows semantic versioning.

Table of Contents

• New and noteworthy
• Fixed issues
• Deprecations
• Potential breaking changes

New and Noteworthy

Fixed issues

• [#​1291] Fix dependency scope for picocli-shell-jline3. Thanks to Sualeh Fatehi for raising this.
• [#​1292] PR to fix dependency scope for picocli-shell-jline3. Thanks to Dejan Stojadinović for the pull request, and Semyon Levin for the review.
• [#​1294] Fix dependency scope for picocli-spring-boot-starter. Thanks to Semyon Levin for raising this.

Deprecations

No features were deprecated in this release.

Potential breaking changes

This release has no breaking changes.

v4.6.0

The picocli community is pleased to announce picocli 4.6.0.

This release contains new features, bug fixes and other enhancements.

Community Contributions

This release contains many, many community contributions, for which I am extremely grateful. Let's give them some credit!

• Andreas Deininger has been contributing to the documentation and other areas for a long time, but recently went into overdrive :-) and contributed many, many new pull requests to improve the documentation. The user manual and Quick Guide now have a "foldable" table of contents, and examples in tabs, with many additional examples in Kotlin, Scala and Groovy. A lot of work went into this! Many thanks, Andreas!
• Marko Mackic contributed a pull request to add IModelTransformer API for user-defined model transformations after initialization and before parsing.
• Sualeh Fatehi contributed a pull request to the picocli-shell-jline3 module that adds a built-in clear command and improves the help command.
• H.Sakata contributed a pull request that adds support for echo and prompt for interactive options and positional parameters.
• Daniel Gray contributed a bug fix to prevent incorrectly defaulting inherited positional params after a subcommand.
• nveeser-google contributed a fix for compiler warnings about Annotation::getClass and assignment in if condition.
• Petr Hála contributed a pull request to add a section on Mocking to user manual.
• Max Rydahl Andersen contributed a pull request to include jbang in the Build Tools section of the user manual.
• David Phillips contributed a section to the user manual on Really Executable JARs.
• Laurent Almeras contributed a pull request to fix the user manual: @ParentObject should be @ParentCommand.
• Mattias Andersson raised the idea of supporting subcommand methods in Groovy scripts.
• Adrian A. raised the idea of using closures in the picocli annotations in Groovy programs instead of specifying a class.
• Nick Cross raised the idea of inheriting @Command attributes with scope=INHERIT.
• Marko Mackic raised the idea of adding a CommandSpec::removeSubcommand method.
• Max Rydahl Andersen raised the idea of supporting Optional<T> type for options and positional parameters.
• Max Rydahl Andersen and David Walluck raised the idea of supporting key-only Map options (to support -Dkey as well as -Dkey=value).
• David Walluck raised the idea of a "preprocessor" parser plugin.
• Jannick Hemelhof raised the idea of supporting @Spec-annotated members in ArgGroup classes.
• Vitaly Shukela raised a bug report: the error message for unmatched positional argument reports an incorrect index when value equals a previously matched argument.
• drkilikil raised a bug report: MissingParameterException should not be thrown when subcommand has required options and help option is specified on parent command.
• Sebastian Thomschke raised a bug report: ReflectionConfigGenerator should not generate method section in subclass config for private superclass methods in reflect-config.json.
• Lukas Heumos added the picocli-based cli-java template to CookieTemple.
• Sualeh Fatehi raised the idea of adding add CommandLine::getFactory accessor method.
• David Walluck contributed a test improvement that allows the tests to run reliably in more environments.

What is in this release

Improved Groovy support: this release introduces a new @PicocliScript2 annotation that adds support for exit codes and @Command-annotated methods to define subcommands. Also, from this release, Groovy programs can use closures in the picocli annotations instead of specifying a class.

From this release, Map options accept key-only parameters, so end users can specify -Dkey as well as -Dkey=value.
There is a new mapFallbackValue attribute that enables this, which can be used to control the value that is put into the map when only a key was specified on the command line.

Also, this release adds support for java.util.Optional<T>: single-value types can be wrapped in an Optional container object when running on Java 8 or higher.
If the option or positional parameter was not specified on the command line, picocli assigns the value Optional.empty() instead of null.

This release also adds support for commands with scope = ScopeType.INHERIT. Commands with this scope have their attributes copied to all subcommands (and sub-subcommands).

New parser plugin: IParameterPreprocessor and new configuration plugin: IModelTransformer.

From this release, @Spec-annotated elements can be used in ArgGroup classes, which can be convenient for validation.

Interactive options and positional parameters can now set echo = true (for non-security sensitive data) so that user input is echoed to the console, and control the prompt text that is shown before asking the user for input.

Help API: this release adds public methods Help.Layout::colorScheme, Help.Layout::textTable, Help.Layout::optionRenderer, Help.Layout::parameterRenderer, and Help::calcLongOptionColumnWidth, making it easier to customize the table format used to lay out options and positional parameters in the usage help message.

CommandSpec API: added method CommandSpec::removeSubcommand.

This is the seventy-fifth public release.
Picocli follows semantic versioning.

Table of Contents

• New and noteworthy
  • New @PicocliScript2 annotation
  • Groovy Closures in Annotations
  • Key-only map parameters
  • System Properties
  • java.util.Optional<T>
  • Inherited Command Attributes
  • Preprocessor Parser Plugin
  • Model Transformations
• Fixed issues
• Deprecations
• Potential breaking changes

New and Noteworthy

New @PicocliScript2 annotation

The older @picocli.groovy.PicocliScript annotation is deprecated from picocli 4.6.
New scripts should use the @picocli.groovy.PicocliScript2 annotation (and associated picocli.groovy.PicocliBaseScript2 base class) instead.
The table below lists the differences between the PicocliBaseScript2 and PicocliBaseScript script base classes.

PicocliBaseScript2	PicocliBaseScript
Subcommands can be defined as @Command-annotated methods in the script.	No support for @Command-annotated methods.
Support for help subcommands (both the built-in one and custom ones).	No support for help subcommands.
Exit code support: scripts can override afterExecution(CommandLine, int, Exception) to call System.exit.	No support for exit code.
Invokes CommandLine::execute. Scripts can override beforeParseArgs(CommandLine) to install a custom IExecutionStrategy.	Execution after parsing is defined in PicocliBaseScript::run and is not easy to customize. Any subcommand and the main script are both executed.
Scripts can override beforeParseArgs(CommandLine) to install a custom IParameterExceptionHandler.	Invalid input handling can be customized by overriding PicocliBaseScript::handleParameterException.
Scripts can override beforeParseArgs(CommandLine) to install a custom IExecutionExceptionHandler.	Runtime exception handling can be customized by overriding PicocliBaseScript::handleExecutionException.
Implements Callable<Object>, script body is transformed to the call method.	Script body is transformed to the runScriptBody method.

Groovy Closures in Annotations

From picocli 4.6, Groovy programs can use closures in the picocli annotations instead of specifying a class.
This can be especially useful in Groovy scripts, where one cannot define a static inner class.

Example:

@​Command(name = "ClosureDemo",
        versionProvider = {
            { -> ["line1" , "line2"] as String[] } as IVersionProvider // <1>
        },
        defaultValueProvider = {
            { argSpec -> "some default" } as IDefaultValueProvider // <2>
        })
class ClosureDemo {
    @&#8203;Option(names = '-x', completionCandidates = {["A", "B", "C"]}) // <3>
    String x

    @&#8203;Option(names = '-y',
            parameterConsumer = {
                { args, argSpec, commandSpec ->  // <4>
                    argSpec.setValue(args.toString() + commandSpec.name())
                    args.clear()
                } as IParameterConsumer
            })
    String y

    @&#8203;Option(names = '-z', converter = [ // requires Groovy 3.0.7
            { { str -> MessageDigest.getInstance(str) } as ITypeConverter } // <5>
    ])
    MessageDigest z
}

When a class is specified, picocli creates an instance of the class. By contrast, when a closure is specified, picocli calls the closure to get an instance.
(To be precise, both of these are delegated to the configured factory, and the default factory implementation supports closures from picocli 4.6.)

As you can see in the above example, each closure in the annotation should contain another closure that has the required type (IVersionProvider, IDefaultValueProvider, etc.)

• <1> Command versionProvider: note the empty parameter list before the -> arrow. This is needed to help the Groovy compiler. The closure must be cast to IVersionProvider.
• <2> Command defaultProvider: return a default value for the specified ArgSpec parameter. The closure must be cast to IDefaultValueProvider.
• <3> Option or Parameters completionCandidates: return a list of Strings. No parameter list or casting is required.
• <4> Option or Parameters parameterConsumer: given a Stack, ArgSpec and CommandSpec, process the remaining arguments. The closure must be cast to IParameterConsumer.
• <5> Option or Parameters type converter takes an array of closures. Groovy 3.0.7 or greater is required: older versions of Groovy ignore closures in class array annotations. Each closure must have a parameter and be cast to ITypeConverter.

Key-only map parameters

By default, picocli expects Map options and positional parameters to look like key=value, that is, the option parameter or positional parameter is expected to have a key part and a value part, separated by a = character. If this is not the case, picocli shows a user-facing error message: Value for ... should be in KEY=VALUE format but was ....

From picocli 4.6, applications can specify a mapFallbackValue to allow end users to specify only the key part. The specified mapFallbackValue is put into the map when end users to specify only a key. The value type can be wrapped in a java.util.Optional. For example:

@​Option(names = {"-P", "--properties"}, mapFallbackValue = Option.NULL_VALUE)
Map<String, Optional<Integer>> properties;

@&#8203;Parameters(mapFallbackValue = "INFO", description = "... ${MAP-FALLBACK-VALUE} ...")
Map<Class<?>, LogLevel> logLevels;

This allows input like the following:

<cmd> --properties=key1 -Pkey2 -Pkey3=3 org.myorg.MyClass org.myorg.OtherClass=DEBUG

The above input would give the following results:

properties = [key1: Optional.empty, key2: Optional.empty, key3: Optional[3]]
logLevels  = [org.myorg.MyClass: INFO, org.myorg.OtherClass: DEBUG]

Note that the option description may contain the ${MAP-FALLBACK-VALUE} variable which will be replaced with the actual map fallback value when the usage help is shown.

System Properties

A common requirement for command line applications is to support the -Dkey=value syntax to allow end users to set system properties.

The example below uses the Map type to define an @Option-annotated method that delegates all key-value pairs to System::setProperty.
Note the use of mapFallbackValue = "" to allow key-only option parameters.

class SystemPropertiesDemo {
    @​Option(names = "-D", mapFallbackValue = "") // allow -Dkey
    void setProperty(Map<String, String> props) {
        props.forEach((k, v) -> System.setProperty(k, v));
    }
}

java.util.Optional<T>

From version 4.6, picocli supports single-value types wrapped in a java.util.Optional container when running on Java 8 or higher.
If the option or positional parameter was not specified on the command line, picocli assigns the value Optional.empty() instead of null.
For example:

@​Option(names = "-x")
Optional<Integer> x;

@&#8203;Option(names = "-D", mapFallbackValue = Option.NULL_VALUE)
Map<String, Optional<Integer>> map;

WARNING: Picocli has only limited support for java.util.Optional types:
only single-value types, and the values in a Map (but not the keys!) can be wrapped in an Optional container.
java.util.Optional cannot be combined with arrays or other Collection classes.

Inherited Command Attributes

Picocli 4.6 adds support for inheriting @Command attributes with the scope = ScopeType.INHERIT annotation.
Commands with this scope have their @Command attributes copied to all subcommands (and sub-subcommands, to any level of depth).

When a subcommand specifies an explicit value in its @Command annotation, this value is used instead of the inherited value.
For example:

@​Command(name = "app", scope = ScopeType.INHERIT,
        mixinStandardHelpOptions = true, version = "app version 1.0",
        header = "App header",
        description = "App description",
        footerHeading = "Copyright%n", footer = "(c) Copyright by the authors",
        showAtFileInUsageHelp = true)
class App implements Runnable {
    @​Option(names = "-x") int x;

    public void run() { System.out.printf("Hello from app %d%n!", x); }

    @​Command(header = "Subcommand header", description = "Subcommand description")
    void sub(@​Option(names = "-y") int y) {
        System.out.printf("Hello app sub %d%n!", y);
    }
}

The app command in the above example has scope = ScopeType.INHERIT, so its @Command properties are inherited by the sub subcommand.

The sub subcommand defines its own header and description, so these are not inherited from the parent command.
The help message for the subcommand looks like this:

Subcommand header
Usage: app sub [-hV] [-y=<arg0>] [@&#8203;<filename>...]
Subcommand description
      [@&#8203;<filename>...]   One or more argument files containing options.
  -h, --help             Show this help message and exit.
  -V, --version          Print version information and exit.
  -y=<arg0>
Copyright
(c) Copyright by the authors

Note that the subcommand has inherited the mixed-in standard help options (--help and --version), the @file usage help, and the footer and footer heading.
It also inherited the version string, shown when the user invokes app sub --version.

When a command has scope = INHERIT, the following attributes are copied to its subcommands:

• all usage help attributes: description, descriptionHeading, header, headerHeading, footer, footerHeading, customSynopsis, synopsisHeading, synopsisSubcommandLabel, abbreviateSynopsis, optionListHeading, parameterListHeading, commandListHeading, exitCodeList, exitCodeListHeading, requiredOptionMarker, showDefaultValues, sortOptions, autoWidth, width, showAtFileInUsageHelp, showEndOfOptionsDelimiterInUsageHelp, and hidden
• exit codes: exitCodeOnSuccess, exitCodeOnUsageHelp, exitCodeOnVersionHelp, exitCodeOnInvalidInput, exitCodeOnExecutionException
• the help and version options mixed in by mixinStandardHelpOptions
• separator between option and option parameter
• version
• versionProvider
• defaultValueProvider
• subcommandsRepeatable
• whether this command is a helpCommand

Attributes that are not copied include:

• command name
• command aliases
• options and parameters (other than the help and version options mixed in by mixinStandardHelpOptions)
• other mixins than mixinStandardHelpOptions
• subcommands
• argument groups

Preprocessor Parser Plugin

Introduced in picocli 4.6, the IParameterPreprocessor is also a parser plugin, similar to IParameterConsumer, but more flexible.

Options, positional parameters and commands can be assigned a IParameterPreprocessor that implements custom logic to preprocess the parameters for this option, position or command.
When an option, positional parameter or command with a custom IParameterPreprocessor is matched on the command line, picocli's internal parser is temporarily suspended, and this custom logic is invoked.

This custom logic may completely replace picocli's internal parsing for this option, positional parameter or command, or augment it by doing some preprocessing before picocli's internal parsing is resumed for this option, positional parameter or command.

The "preprocessing" actions can include modifying the stack of command line parameters, or modifying the model.

Example use case

This may be useful when disambiguating input for commands that have both a positional parameter and an option with an optional parameter.
For example, suppose we have a command with the following synopsis:

edit [--open[=<editor>]] <file>

One of the limitations of options with an optional parameter is that they are difficult to combine with positional parameters.

With a custom parser plugin, we can customize the parser, such that VALUE in --option=VALUE is interpreted as the option parameter, and in --option VALUE (without the = separator), VALUE is interpreted as the positional parameter.
The code below demonstrates:

@​Command(name = "edit")
class Edit {

    @​Parameters(index = "0", description = "The file to edit.")
    File file;

    enum Editor { defaultEditor, eclipse, idea, netbeans }

    @​Option(names = "--open", arity = "0..1", preprocessor = Edit.MyPreprocessor.class,
        description = {
            "Optionally specify the editor to use; if omitted the default editor is used. ",
            "Example: edit --open=idea FILE opens IntelliJ IDEA (notice the '=' separator)",
            "         edit --open FILE opens the specified file in the default editor"
        })
    Editor editor = Editor.defaultEditor;
    
    static class MyPreprocessor implements IParameterPreprocessor {
        public boolean preprocess(Stack<String> args,
                                  CommandSpec commandSpec,
                                  ArgSpec argSpec,
                                  Map<String, Object> info) {
            // we need to decide whether the next arg is the file to edit
            // or the name of the editor to use...
            if (" ".equals(info.get("separator"))) { // parameter was not attached to option

                // act as if the user specified --open=defaultEditor
                args.push(Editor.defaultEditor.name());
            }
            return false; // picocli's internal parsing is resumed for this option
        }
    }
}

With this preprocessor, the following user input gives the following command state:

v4.5.2

The picocli community is pleased to announce picocli 4.5.2.

This release contains bug fixes and enhancements:

• Auto-enable ANSI colors on MSYS2 terminals.
• Abbreviated options are now matched correctly even when value attached with '=' separator.
• The built-in HelpCommand now respects subcommands case-sensitivity and abbreviations.
• Required parameters no longer consume negated options.
• Positional parameters in Argument Groups no longer result in ArithmeticException: / by zero exceptions.
• The user manual now has tabs showing examples in languages other than Java.
  This is a work in progress: many examples still only have a Java version.
  Contributions welcome!
• Many, many documentation enhancements, most of which contributed by the community.

Many thanks to the picocli community who contributed 28 pull requests in this release!
Please see the Fixed Issues section below for the individual contributors. Great work!

This is the seventy-fourth public release.
Picocli follows semantic versioning.

Table of Contents

• New and noteworthy
• Fixed issues
• Deprecations
• Potential breaking changes

New and Noteworthy

The user manual now has tabs showing examples in languages other than Java.
This is a work in progress: many examples still only have a Java version.
Contributions welcome!

Fixed issues

• [#​1186] Enhancement: Auto-enable ANSI colors on MSYS2 (Git for Windows, MSYS2-based Windows Terminal shells, etc.). Thanks to Sysmat for raising this.
• [#​1162] Bugfix: Abbreviated options are not matched if value attached with '=' separator (like -x=3). Thanks to Chris Laprun for raising this.
• [#​1156][#​1172] Bugfix: the built-in HelpCommand now respects subcommands case-sensitivity and abbreviations. Thanks to NewbieOrange for the pull request.
• [#​1197] Bugfix: required parameters should not consume negated options. Thanks to Kevin Turner for raising this.
• [#​1213] Bugfix: @Parameters in @ArgGroup should not result in ArithmeticException: / by zero. Thanks to Loren Keagle for raising this.
• [#​1158] DOC: Fix broken links to GraalVM repo. Thanks to Andreas Deininger for the pull request.
• [#​1155] DOC: Fix sample code in chapter "Validation". Thanks to Andreas Deininger for the pull request.
• [#​1157] DOC: Fix typo "a argument group" in user manual. Thanks to sabrina for raising this.
• [#​1160] DOC: Added section Was a Value Defaulted? to the user manual.
• [#​1161] DOC: Fix typo "4,2" (should be 4.2) in user manual. Thanks to sabrina for raising this.
• [#​1165] DOC: Fix jline3 example: add AnsiConsole::systemUninstall in finally clause. Thanks to David Walluck for raising this.
• [#​1168][#​1169] DOC: Ensure org.jline.terminal.Terminal is closed when done. Thanks to David Walluck for the pull request.
• [#​1167] DOC: Fix broken links in Quick Guide. Thanks to Andreas Deininger for the pull request.
• [#​1171] DOC: Various documentation improvements. Thanks to Andreas Deininger for the pull request.
• [#​1173] DOC: Improve example applications for the user manual and Quick Guide. Thanks to Andreas Deininger for the pull request.
• [#​1175] DOC: section on compatible versions to picocli-shell-jline3/README.md. Thanks to Nick Cross for raising this.
• [#​1176] DOC: Update JLine picocli-shell-jline3 example to 3.16.0. Thanks to Nick Cross for the pull request.
• [#​890][#​1187] DOC: Extend and improve subcommands documentation. Thanks to Andreas Deininger for the pull request.
• [#​1190] DOC: Improve InetSocketAddressConverter demo. Thanks to Andreas Deininger for the pull request.
• [#​1192] DOC: Fix broken links in documentation. Thanks to Andreas Deininger for the pull request.
• [#​1196] DOC: Quick Guide examples can now be executed on the documentation page via JDoodle.com. Thanks to Andreas Deininger for the pull request.
• [#​1200] DOC: User manual checksum example can now be executed on the documentation page via JDoodle.com. Thanks to Andreas Deininger for the pull request.
• [#​1199] DOC: Fix paramLabel in examples. Thanks to Andreas Deininger for the pull request.
• [#​1198] DOC: Add copy button to code blocks. Thanks to Andreas Deininger for the pull request.
• [#​1201] DOC: User manual checksum example: add Kotlin source code on second tab. Thanks to Andreas Deininger for the pull request.
• [#​1202] DOC: Update to latest Asciidoctor gradle plugin. Thanks to Andreas Deininger for the pull request.
• [#​1203] DOC: Replace 'coderay' source code highlighter with 'rouge' to support Kotlin, Scala and Groovy. Thanks to Andreas Deininger for the pull request.
• [#​1205] DOC: User manual checksum example: add more tabs for Groovy, Groovy script and Scala. Thanks to Andreas Deininger for the pull request.
• [#​1208] DOC: Fix: Show copy buttons in code blocks with latest Asciidoctor gradle plugin. Thanks to Andreas Deininger for the pull request.
• [#​1209] DOC: Show Maven coordinates in JLine2/3 README. Thanks to Jiří Holuša for the pull request.
• [#​1210] DOC: User manual subcommands example: add tab with Kotlin source code. Thanks to Andreas Deininger for the pull request.
• [#​1211] DOC: User manual subcommands section: add several tabs with Kotlin source code. Thanks to Andreas Deininger for the pull request.
• [#​1170] TEST: Ensure ANSI is disabled in ManPageGeneratorTest regardless of environment. Thanks to David Walluck for the pull request.
• [#​1166][#​1103] TEST: Ensure ANSI is disabled in TracerTest regardless of environment. Thanks to David Walluck for the pull request.
• [#​1179] TEST: Use .invalid domain name for InetAddress test. Thanks to David Phillips for the pull request.
• [#​1178] BUILD: Run Travis build on macOS. Thanks to David Phillips for the pull request.
• [#​1192] Dependency Upgrade: Bump AsciiDoctor to 2.1.0 from 1.6.2. Thanks to Andreas Deininger for the pull request.

Deprecations

No features were deprecated in this release.

Potential breaking changes

This release has no breaking changes.

v4.5.1

The picocli community is pleased to announce picocli 4.5.1.

This release contains bug fixes and enhancements.

Fixed bug in the picocli-codegen annotation processor that resulted in errors in native images that used ManPageGenerator as subcommand.

Suppress generation of Gradle Module Metadata, to fix Gradle build failures for projects using picocli 4.4.0 or 4.5.0.

Fixed terminal width detection on macOS.

The user manual now has a new section on Validation. Various other documentation improvements.

This is the seventy-third public release.
Picocli follows semantic versioning.

Table of Contents

• New and noteworthy
• Fixed issues
• Deprecations
• Potential breaking changes

New and Noteworthy

Fixed issues

• [#​1151] Bugfix: ManPageGenerator as subcommand with native-image throws exception. Thanks to Sebastian Hoß for raising this.
• [#​1152] Bugfix: Gradle build fail when using picocli 4.4.0 or 4.5.0: Gradle Module Metadata for picocli 4.4.0+ missing from Maven Central. Thanks to Frank Pavageau for reporting this.
• [#​1150] Bugfix: Fix terminal width detection on macOS. Thanks to David Phillips for the pull request.
• [#​1142] DOC: Update Kotlin GraalVM native image example - Update native image gradle plugin. Now supports jdk 11. Thanks to OndrejMalek for the pull request.
• [#​1153] DOC: Fix documentation leading code quote. Thanks to sabrina for raising this.
• [#​1147] DOC: Add documentation on how to do custom parameter validation. Thanks to Loren Keagle for raising this.

Deprecations

No features were deprecated in this release.

Potential breaking changes

This release has no breaking changes.

v4.5.0

The picocli community is pleased to announce picocli 4.5.0.

This release contains bug fixes and enhancements.

The ColorScheme class now has new methods stackTraceText and richStackTraceString, which can be convenient when creating custom error handlers with colors.

Various bugfixes in the picocli-codegen annotation processor.

The user manual now has anchor links before all section titles.

This is the seventy-second public release.
Picocli follows semantic versioning.

Table of Contents

• New and noteworthy
• Fixed issues
• Deprecations
• Potential breaking changes

New and Noteworthy

Fixed issues

• [#​1129] API: Add methods ColorScheme::stackTraceText(Throwable) and ColorScheme::richStackTraceString(Throwable).
• [#​1124] Enhancement: automatically generate a better summary in the AutoComplete.GenerateCompletion generated man page.
• [#​1126] Enhancement: Make picocli trace levels case-insensitive.
• [#​1128] Enhancement: ParameterException caused by TypeConversionException now have their cause exception set.
• [#​1137] Bugfix: The picocli-codegen annotation processor causes the build to fail with a ClassCastException when an option has completionCandidates defined.
• [#​1134] Bugfix: The picocli-codegen annotation processor should allow @Spec-annotated field in classes implementing IVersionProvider.
• [#​1138] Bugfix: The picocli-codegen annotation processor no longer gives FATAL ERROR: picocli.CommandLine$InitializationException: ArgGroup has no options or positional parameters, and no subgroups during incremental compilation in Intelli/J IDEA.
• [#​1127] DOC: Custom ShortErrorMessageHandler manual example should use bold red for error message.
• [#​1130] DOC: Clarify how to run picocli-based applications.
• [#​1131] DOC: Add anchor links before section titles in user manual.

Deprecations

No features were deprecated in this release.

Potential breaking changes

This release has no breaking changes.

---

Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box.

---

This PR has been generated by WhiteSource Renovate. View repository job log here.