Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(deps): update picocli.version to v4.6.2 #648

Merged
merged 1 commit into from
Nov 29, 2021

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Nov 23, 2021

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
info.picocli:picocli-codegen (source) 4.5.2 -> 4.6.2 age adoption passing confidence
info.picocli:picocli (source) 4.5.2 -> 4.6.2 age adoption passing confidence

Release Notes

remkop/picocli

v4.6.2

Compare Source

The picocli community is pleased to announce picocli 4.6.2.

This release includes bugfixes and enhancements. Many improvements in the documentation.

Thanks to the many people in the picocli community for raising issues and contributing pull requests to fix issues!

From this release, picocli uses system properties sun.stdout.encoding and sun.stderr.encoding when creating the PrintWriters returned by CommandLine::getOut and CommandLine::getErr.
When these system properties do not exist, picocli falls back to the default charset (determined by file.encoding).
This addresses an issue on Windows, where the default charset is not the same as the encoding for its console (often the older cp437 codepage on English-language versions of Windows).
Note that these system properties seem to have been introduced in Java 8 (although I cannot find it in the JDK 8 release notes) and may not exist on earlier JVMs or on JVMs other than the Oracle and OpenJDK implementations.

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

Table of Contents

New and Noteworthy

Fixed issues

  • [#​1422] API: Un-deprecate the @Option help attribute; it is useful for custom help options. Thanks to kaushalkumar for raising this.
  • [#​1337][#​1338] Enhancement: prevent spurious WARNING: tag not found in include file messages when generating man pages. Thanks to Philip Crotwell for the pull request.
  • [#​1340] Enhancement: add xref to generated man page document to link to subcommands from the parent command page. Thanks to Philip Crotwell for the pull request.
  • [#​1351][#​1362] Enhancement: avoid calling option completionCandidates when displaying usage help if ${COMPLETION-CANDIDATES} is not specified in description. Thanks to Wenhao ZHANG, sustc11810424 and Yining Tang for the pull request.
  • [#​1303] Bugfix: Prevent IllegalArgumentException: argument type mismatch error in method subcommands with inherited mixed-in standard help options. Thanks to Andreas Deininger for raising this.
  • [#​1300] Bugfix: Avoid spurious warning "Could not set initial value for field boolean" when reusing CommandLine with ArgGroup. Thanks to Yashodhan Ghadge for raising this.
  • [#​1316] Bugfix: Avoid DuplicateOptionAnnotationsException thrown on mixinStandardHelpOptions for subcommands when parent has scope = INHERIT by picocli-codegen annotation processor. Thanks to Philippe Charles for raising this.
  • [#​1319] Bugfix: Avoid DuplicateOptionAnnotationsException when parent has inherited mixed-in help options and the built-in HelpCommand subcommand. Thanks to Andreas Deininger for raising this.
  • [#​1331] Bugfix: Avoid IllegalArgumentException when parent has no standard help options and scope = INHERIT, while subcommand does have mixed-in standard help options. Thanks to Andreas Deininger for raising this.
  • [#​1381][#​1382] Bugfix: Default value of option in repeated subcommand was not applied correctly. Thanks to sfeuerhahn for the pull request.
  • [#​1434][#​1435] CommandSpec.remove(arg) should also remove the arg from the args collection in the CommandSpec. Thanks to kaushalkumar for the pull request.
  • [#​1404] Bugfix/Enhancement: Print paramLabel only when it could exist. Thanks to João Guerra for the pull reqeust.
  • [#​1320][#​1321] Bugfix/Enhancement: Use system properties sun.stdout.encoding and sun.stderr.encoding when creating the PrintWriters returned by CommandLine::getOut and CommandLine::getErr. Thanks to Philippe Charles for the investigation and the pull request.
  • [#​1431] Bugfix/enhancement: .gitattributes should include HTML files to convert CRLF to LF. Thanks to wenhoujx for pointing this out.
  • [#​1388][#​1430] Bugfix: Fix subcommand aliases autocomplete regression. Thanks to NewbieOrange for the pull request.
  • [#​1415] Bugfix/DOC: fix NullPointerException in README Example. Thanks to shannonbay for raising this.
  • [#​1421] Bugfix/DOC: execute method in RunAll, RunFirst and RunLast should not be deprecated. Thanks to Gamal DeWeever for raising this.
  • [#​1326][#​1339] DOC: Added documentation and examples for controlling the locale. Thanks to Andreas Deininger for the pull request.
  • [#​1296] DOC: add Kotlin code samples to user manual; other user manual improvements. Thanks to Andreas Deininger for the pull request.
  • [#​1299] DOC: Link to IParameterPreprocessor from IParameterConsumer javadoc. Thanks to Andreas Deininger for the pull request.
  • [#​1304] DOC: Manual, chapter '17.9 Inherited Command Attributes': added Kotlin version of code sample. Thanks to Andreas Deininger for the pull request.
  • [#​1305] DOC: Document use of IParameterConsumer as n-ary type converter. Thanks to Martin for raising this.
  • [#​1307] DOC: Added CAUTION admonitions, Kotlin code sample. Thanks to Andreas Deininger for the pull request.
  • [#​1308] DOC: Add example for Option converter, improve text for default values. Thanks to Abhijit Sarkar for raising this.
  • [#​1314] DOC: Fix use of deprecated Maven properties in README. Thanks to Philippe Charles for the pull request.
  • [#​1323] DOC: Update Testing section of the user manual for Stefan Birkner's library System-Lambda.
  • [#​1325] DOC: Add section on Short and Long Option Columns to user manual. Thanks to Andrei Ciobanu for raising this.
  • [#​1336] DOC: Kotlin sample code, documentation improvements. Thanks to Andreas Deininger for the pull request.
  • [#​1342] DOC: Improve user manual chapter 28.3 'Testing the Exit Code'. Thanks to Andreas Deininger for the pull request.
  • [#​1344] DOC: Documentation, chapter 'Testing environment variables:': add Kotlin test sample. Thanks to Andreas Deininger for the pull request.
  • [#​1443] DOC: Fix incorrect method name setLongOptionsMaxWidth to setUsageHelpLongOptionsMaxWidth in user manual section 'Long Option Column Width'. Thanks to kunlk for raising this.
  • [#​1360][#​1359] DOC: add JReleaser as packaging option. Thanks to Andres Almiray for the pull request.
  • [#​1363][#​1364] DOC: Add caution on Variable interpolation in Kotlin. Thanks to MagnusMG for the pull request.
  • [#​1397][#​1399] DOC: Update Jline2 README.md to add some recommended workaround about ANSI incompatible terminals. Thanks to Simon for the pull request.
  • [#​1398][#​1400] DOC: Arity of boolean options is now documented correctly. Thanks to João Guerra for the pull request.
  • [#​1428][#​1433] DOC: Add section about subcommands with the same name as option default value. Thanks to cbcmg for the pull request.
  • [#​1390][#​1432] DOC: Update examples to not throw Exception from main method. Thanks to wenhoujx for the pull request.
  • [#​1423] DOC: Fixed broken link in README.md to annotation processor documentation. Thanks to Sevy007 for raising this.
  • [#​1449] DOC: Fix typo in picocli-shell-jline2/README.md. Thanks to Ahmed Ashour for the pull request.
  • [#​1426] Fix README adoption logos. Thanks to NewbieOrange for the pull request.
  • [#​1313] DEP: Bump jline3Version in order to avoid stackoverflow error. Thanks to Rupert Madden-Abbott for the pull request.
  • [#​1455] DEP: Bump spring-boot version to 2.5.6.
  • [#​1369][#​1371] Upgrade jline3 to version 3.19.0 to avoid "ReadConsoleInputW failed: Incorrect function" error. Thanks to auricgoldfinger for the pull request.
  • [#​1336] BUILD: Bump Spring Boot, Gradle and Kotlin to latest version. Thanks to Andreas Deininger for the pull request.
  • [#​1327] BUILD: fix incorrect version in MANIFEST.MF. Thanks to Fiouz for the pull request.
  • [#​1328] BUILD: Upgrade Gradle to 6.8.2 and enable official Gradle Wrapper Validation GitHub Action. Thanks to Fiouz for the pull request.
  • [#​1329] BUILD: OSGi manifest entry in picocli-4.6.0.jar should not require groovy. Thanks to Fiouz for raising this.
  • [#​1330] BUILD: use type-safe DSL instead of direct XML manipulation to generate pom.xml. Thanks to Fiouz for the pull request.
  • [#​1332] BUILD: Bumping asciidoctor + asciidoctor gradle plugin to latest versions. Thanks to Andreas Deininger for the pull request.
  • [#​1413] BUILD: Improve Travis CI build Performance. Thanks to YunLemon for the pull request.
  • [#​1322] BUILD: switch from Bintray jcenter to Maven Central.

Deprecations

No features were deprecated in this release.

The @Option help attribute is no longer deprecated from this release; it is useful for custom help options.

Potential breaking changes

This release has no breaking changes.

v4.6.1

Compare Source

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

No features were deprecated in this release.

Potential breaking changes

This release has no breaking changes.

v4.6.0

Compare Source

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

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:

@&#8203;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:

@&#8203;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 {
    @&#8203;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:

@&#8203;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:

@&#8203;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 {
    @&#8203;Option(names = "-x") int x;

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

    @&#8203;Command(header = "Subcommand header", description = "Subcommand description")
    void sub(@&#8203;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:

@&#8203;Command(name = "edit")
class Edit {

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

    enum Editor { defaultEditor, eclipse, idea, netbeans }

    @&#8203;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:


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 these updates again.


  • If you want to rebase/retry this PR, click this checkbox.

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

@algomaster99 algomaster99 merged commit 49573d0 into master Nov 29, 2021
@algomaster99 algomaster99 deleted the renovate/picocli.version branch November 29, 2021 14:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants