Picocli is a modern framework for building powerful, user-friendly, GraalVM-enabled command line apps with ease. It supports colors, autocompletion, subcommands, and more. In 1 source file so apps can include as source & avoid adding a dependency. Written in Java, usable from Groovy, Kotlin, Scala, etc.
The picocli community is pleased to announce picocli 4.5.2.
This release contains bug fixes and enhancements:
HelpCommand
now respects subcommands case-sensitivity and abbreviations.ArithmeticException: / by zero
exceptions.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.
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!
-x=3
). Thanks to Chris Laprun for raising this.HelpCommand
now respects subcommands case-sensitivity and abbreviations. Thanks to NewbieOrange for the pull request.@Parameters
in @ArgGroup
should not result in ArithmeticException: / by zero
. Thanks to Loren Keagle for raising this.AnsiConsole::systemUninstall
in finally
clause. Thanks to David Walluck for raising this.org.jline.terminal.Terminal
is closed when done. Thanks to David Walluck for the pull request.picocli-shell-jline3/README.md
. Thanks to Nick Cross for raising this.picocli-shell-jline3
example to 3.16.0. Thanks to Nick Cross for the pull request.checksum
example can now be executed on the documentation page via JDoodle.com. Thanks to Andreas Deininger for the pull request.paramLabel
in examples. Thanks to Andreas Deininger for the pull request.checksum
example: add Kotlin source code on second tab. Thanks to Andreas Deininger for the pull request.checksum
example: add more tabs for Groovy, Groovy script and Scala. Thanks to Andreas Deininger for the pull request.subcommands
example: add tab with Kotlin source code. Thanks to Andreas Deininger for the pull request.subcommands
section: add several tabs with Kotlin source code. Thanks to Andreas Deininger for the pull request.ManPageGeneratorTest
regardless of environment. Thanks to David Walluck for the pull request.TracerTest
regardless of environment. Thanks to David Walluck for the pull request..invalid
domain name for InetAddress
test. Thanks to David Phillips for the pull request.No features were deprecated in this release.
This release has no breaking changes.
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.
ManPageGenerator
as subcommand with native-image throws exception. Thanks to Sebastian Hoß for raising this.No features were deprecated in this release.
This release has no breaking changes.
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.
ColorScheme::stackTraceText(Throwable)
and ColorScheme::richStackTraceString(Throwable)
.AutoComplete.GenerateCompletion
generated man page.ParameterException
caused by TypeConversionException
now have their cause exception set.picocli-codegen
annotation processor causes the build to fail with a ClassCastException
when an option has completionCandidates
defined.picocli-codegen
annotation processor should allow @Spec
-annotated field in classes implementing IVersionProvider
.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.No features were deprecated in this release.
This release has no breaking changes.
The picocli community is pleased to announce picocli 4.4.0.
This release contains over 45 bugfixes, enhancements, and new features.
A major new feature in this release is support for abbreviated options and subcommands. When abbreviations are enabled, users can specify the initial letter(s) of the first "component" and optionally of one or more subsequent components of an option or subcommand name. "Components" are parts of a name, separated by -
dash characters or by upper/lower case. So for example, both --CamelCase
and --kebab-case
have two components. For details see the New and Noteworthy section below.
Another important change are parser fixes and improvements: the parser will no longer assign values that match an option name to options that take a parameter, unless the value is in quotes. Also, values that resemble, but not exactly match, option names are now treated more consistently and parser behaviour for such values is configurable.
Also worth hightlighting: from this release, the ManPageGenerator
tool can be used as a subcommand in your application.
There are many more improvements in this release: it is now easier to customize the usage help message, there are JANSI fixes, and other bugfixes and enhancements. See the Fixed Issues list for details.
This is the seventy-first public release. Picocli follows semantic versioning.
Since picocli 4.4, the parser can recognize abbreviated options and subcommands.
This needs to be enabled explicitly with CommandLine::setAbbreviatedOptionsAllowed
and CommandLine::setAbbreviatedSubcommandsAllowed
.
When abbreviations are enabled, users can specify the initial letter(s) of the first component and optionally of one or more subsequent components of an option or subcommand name.
"Components" are separated by -
dash characters or by case, so for example, both --CamelCase
and --kebab-case
have two components.
NOTE: When case sensitivity is disabled, only the -
dash character can be used to separate components.
Examples of valid abbreviations:
Option or Subcommand | Recognized Abbreviations
-------------------- | ------------------------
--veryLongCamelCase | --very, --vLCC --vCase
--super-long-option | --sup, --sLO, --s-l-o, --s-lon, --s-opt, --sOpt
some-long-command | so, sLC, s-l-c, soLoCo, someCom
When the user specifies input that can match multiple options or subcommands, the parser throws a ParameterException
. When applications use the execute
method, a short error message and the usage help is displayed to the user.
For example, given a command with subcommands help
and hello
, then ambiguous user input like hel
will show this error message:
Error: 'hel' is not unique: it matches 'hello', 'help'
When an argument can match both a long option and a set of clustered short options, picocli matches the long option.
For example:
class AbbreviationsAndPosix {
@Option(names = "-A") boolean a;
@Option(names = "-B") boolean b;
@Option(names = "-AaaBbb") boolean aaaBbb;
}
AbbreviationsAndPosix app = new AbbreviationsAndPosix();
new CommandLine(app).setAbbreviatedOptionsAllowed(true).parseArgs("-AB");
assertTrue(app.aaaBbb);
assertFalse(app.a);
assertFalse(app.b);
When abbreviated options are enabled, user input -AB
will match the long -AaaBbb
option, but not the -A
and -B
options.
Options that take a parameter previously were able to take option names as the parameter value. From this release, this is no longer possible. The parser will no longer assign values that match an option name to an option, unless the value is in quotes. For example:
class App {
@Option(names = "-x") String x;
@Option(names = "-y") String y;
public static void main(String... args) {
App app = new App();
new CommandLine(app).setTrimQuotes(true).parseArgs(args);
System.out.printf("x='%s', y='%s'%n", app.x, app.y);
}
}
In previous versions of picocli, the above command would accept input -x -y
, and the value -y
would be assigned to the x
String field. From this release, the above input will be rejected with an error message indicating that the -x
option requires a parameter.
If it is necessary to accept values that match option names, these values need to be quoted. For example:
java App -x="-y"
This will print the following output:
x='-y', y='null'
Vararg positional arguments no longer consume unmatched options unless configured to do so. For example:
class App {
@Parameters(arity = "*") String[] positionals;
}
In previous versions of picocli, the parser behaviour was not consistent:
-z 123
would be rejected with error "Unmatched argument: '-z'
123 -z
would be accepted and the positionals
String array would contain two values, 123
and -z
(Note that this problem only occurred with multi-value positional parameters defined with variable arity: arity = "*"
.)
From this release, both of the above input sequences will be rejected with an error message indicating that -z
is an unknown option. As before, to accept such values as positional parameters, call CommandLine::setUnmatchedOptionsArePositionalParams
with true
.
By default, options accept parameter values that "resemble" (but don't exactly match) an option.
This release introduces a CommandLine::setUnmatchedOptionsAllowedAsOptionParameters
method that makes it possible to configure the parser to reject values that resemble options as option parameters. Setting it to false
will result in values resembling option names being rejected as option values.
For example:
class App {
@Option(names = "-x") String x;
}
By default, a value like -z
, which resembles an option, is accepted as the parameter for -x
:
App app = new App();
new CommandLine(app).parseArgs("-x", "-z");
assertEquals("-z", app.x);
After setting the unmatchedOptionsAllowedAsOptionParameters
parser option to false
, values resembling an option are rejected as parameter for -x
:
new CommandLine(new App())
.setUnmatchedOptionsAllowedAsOptionParameters(false)
.parseArgs("-x", "-z");
This will throw an UnmatchedArgumentException
with message:
"Unknown option '-z'; Expected parameter for option '-x' but found '-z'"
NOTE: Negative numbers are not considered to be unknown options, so even when unmatchedOptionsAllowedAsOptionParameters
is set to false
, option parameters like -123
, -NaN
, -Infinity
, -#ABC
and -0xCAFEBABE
will not be rejected for resembling but not matching an option name.
From picocli 4.4, the ManPageGenerator
tool can be used as a subcommand in your application, with the usual syntax:
import picocli.codegen.docgen.manpage.ManPageGenerator;
@Command(subcommands = ManPageGenerator.class)
...
To use the ManPageGenerator
tool as a subcommand, you will need the picocli-codegen
jar in your classpath.
CommandLine::is/setUnmatchedOptionsAllowedAsOptionParameters
to disallow option parameter values resembling option names. Thanks to Peter Murray-Rust for raising this.ParseResult::expandedArgs
to return the list of arguments after @-file
expansion. Thanks to Kevin Bedi for the pull request.Help::allSubcommands
to return all subcommands, including hidden ones. Clarify the semantics of Help::subcommands
.Help::optionListExcludingGroups
to return a String with the rendered section of the usage help containing only the specified options, including hidden ones.Help::parameterList(List<PositionalParamSpec>)
to return a String with the rendered section of the usage help containing only the specified positional parameters, including hidden ones.Help::commandList(Map<String, Help>)
to return a String with the rendered section of the usage help containing only the specified subcommands, including hidden ones.Help::optionListGroupSections
to return a String with the rendered section of the usage help containing only the option groups.Help::createDefaultOptionSort
to create a Comparator
that follows the command and options' configuration.Help::createDefaultLayout(List<OptionSpec>, List<PositionalParamSpec>, ColorScheme)
to create a layout for the specified options and positionals.ArgumentGroupSpec::allOptionsNested
and ArgumentGroupSpec::allPositionalParametersNested
.Help.Layout::addAllOptions
and Help.Layout::addAllPositionals
, to show all specified options, including hidden ones.Help::optionSectionGroups
to get argument groups with a header.Help::createDetailedSynopsisOptionsText
to specify which options to show in the synopsis.Help::makeSynopsisFromParts
for building complex synopsis strings; synopsis now shows non-group options before argument groups, for a more natural synopsis when groups contain only positional parameters.Help
methods by providing a custom option list and customizing the synopsis.GenerateCompletion
command no longer needs to be a direct subcommand of the root command. Thanks to Philippe Charles for the pull request.@Command
-annotated methods no longer need the enclosing class to have a @Command
annotation.ParserSpec::toString
output settings in alphabetic order.optionsCaseInsensitive
and subcommandsCaseInsensitive
settings.Help.Column
equals
, hashCode
and toString
methods to facilitate testing.ManPageGenerator
to ensure generated AsciiDoc man pages use UTF-8 encoding. Thanks to Andreas Deininger for the pull request.ManPageGenerator
now correctly excludes hidden options, parameters, and subcommands from man page generation. Thanks to Brian Demers for the pull request.unmatchedOptionsArePositionalParams
is configured. Thanks to Chris Smowton for raising this.optionListHeading
when all options are hidden.CommandLine.Help
constructor no longer calls overridable methods addAllSubcommands
and createDefaultParamLabelRenderer
.List<>
option in @ArgGroup
, group incorrectly appears twice in the synopsis. Thanks to kap4lin for raising this.ParserSpec::initFrom
was not copying useSimplifiedAtFiles
.UsageMessageSpec::width
and UsageMessageSpec::longOptionsMaxWidth
is no longer ignored.CommandSpec
is now correctly used in the CommandSpec
copy for repeatable subcommands. Thanks to Michael Kunz for the pull request.descriptionKeys
for @file
and EndOfOptions (--) delimiter in resource bundles.@deprecated
Javadoc tag for Help::addSubcommand
.No features were deprecated in this release.
The parser behaviour has changed: picocli will no longer assign values that match an option name to options that take a parameter, unless the value is in quotes. Applications that rely on this behaviour need to use quoted values.
Unmatched arguments that look like options now result in an error message Unknown option: '-unknown'
.
Previously, the error message was: Unmatched argument: '-unknown'
.
This release changes the synopsis for commands with argument groups: the synopsis now shows the non-group options before argument groups, where previously argument groups were shown first.
This gives a more natural synopsis when groups contain only positional parameters.
The picocli community is pleased to announce picocli 4.3.2.
This release fixes a bug where the stack trace of an exception in the business logic would omit nested cause exceptions.
This is the seventieth public release. Picocli follows semantic versioning.
[#1048][#1049] Bugfix: Cause exception not printed by default execution exception handler. Thanks to Neko Null for the pull request.
No features were deprecated in this release.
This release has no breaking changes.
The picocli community is slightly embarrassed to announce picocli 4.3.1. :-)
This release fixes some critical bugs:
IllegalArgumentException: wrong number of arguments
was thrown when the @Option(scope = INHERIT)
feature is used in a command that has subcommands defined in @Command
-annotated methodsNullPointerException
was thrown in DefaultParamLabelRenderer.renderParameterLabel
for programmatically built models that have a non-null
split
regex and do not have a splitSynopsisLabel
String.isEmpty
method, which prevented picocli from running on Java 5: this method was introduced in Java 6See Fixed issues for the full list of changes.
This is the sixty-nineth public release. Picocli follows semantic versioning.
[#1042] Bugfix: "wrong number of arguments" exception when using inherited options with @Command
-annotated methods. Thanks to Garret Wilson for raising this.
[#1043] Bugfix: NullPointerException thrown in DefaultParamLabelRenderer.renderParameterLabel
for programmatically built models that have a non-null
split
regex and do not have a splitSynopsisLabel
.
[#1044] Bugfix: only display splitSynopsisLabel
in usage help message if the option has a split
regex. Thanks to Andreas Deininger for raising this.
[#1045] Bugfix: replace use of Java 6 API String.isEmpty
with picocli-internal Java 5 equivalent.
[#1046] DOC: mention picocli's programmatic API and link to the programmatic API documentation from the user manual.
No features were deprecated in this release.
This release has no breaking changes.
The picocli community is pleased to announce picocli 4.3.0.
This is a fairly big release with 70 tickets closed, and over 50 bugfixes and enhancements. Many thanks to the picocli community who contributed 21 pull requests!
A major theme of this release is sharing options between commands:
scope = ScopeType.INHERIT
are shared with all subcommands (and sub-subcommands, to any level of depth). Applications can define an inherited option on the top-level command, in one place, to allow end users to specify this option anywhere: not only on the top-level command, but also on any of the subcommands and nested sub-subcommands.@Spec(MIXEE)
-annotated field, and picocli will inject the CommandSpec
of the command receiving this mixin (the "mixee") into this field. This is useful for mixins containing shared logic, in addition to shared options and parameters.Another major theme is improved support for positional parameters:
index = "..."
attribute are now automatically assigned an index based on the other positional parameters in the command. One use case is mixins with positional parameters.Other improvements:
Help.ColorScheme
methods errors
and stackTraces
.--
in the options list with the @Command(showEndOfOptionsDelimiterInUsageHelp = true)
annotation.Runnable
or Callable
.This is the sixty-eighth public release. Picocli follows semantic versioning.
This release adds support for "inherited" options. Options defined with scope = ScopeType.INHERIT
are shared with all subcommands (and sub-subcommands, to any level of depth). Applications can define an inherited option on the top-level command, in one place, to allow end users to specify this option anywhere: not only on the top-level command, but also on any of the subcommands and nested sub-subcommands.
Below is an example where an inherited option is used to configure logging.
@Command(name = "app", subcommands = Sub.class)
class App implements Runnable {
private static Logger logger = LogManager.getLogger(App.class);
@Option(names = "-x", scope = ScopeType.LOCAL) // option is not shared: this is the default
int x;
@Option(names = "-v", scope = ScopeType.INHERIT) // option is shared with subcommands, sub-subcommands, etc
public void setVerbose(boolean verbose) {
// Configure log4j.
// This is a simplistic example: you probably only want to modify the ConsoleAppender level.
Configurator.setRootLevel(verbose ? Level.DEBUG : Level.INFO);
}
public void run() {
logger.debug("-x={}", x);
}
}
@Command(name = "sub")
class Sub implements Runnable {
private static Logger logger = LogManager.getLogger(Sub.class);
@Option(names = "-y")
int y;
public void run() {
logger.debug("-y={}", y);
}
}
Users can specify the -v
option on either the top-level command or on the subcommand, and it will have the same effect.
# the -v option can be specified on the top-level command
java App -x=3 -v sub -y=4
Specifying the -v
option on the subcommand will have the same effect. For example:
# specifying the -v option on the subcommand also changes the log level
java App -x=3 sub -y=4 -v
NOTE: Subcommands don't need to do anything to receive inherited options, but a potential drawback is that subcommands do not get a reference to inherited options.
Subcommands that need to inspect the value of an inherited option can use the @ParentCommand
annotation to get a reference to their parent command, and access the inherited option via the parent reference.
Alternatively, for such subcommands, sharing options via mixins may be a more suitable mechanism.
By default, all options and subcommands are case sensitive. Case sensitivity can be switched off globally, as well as on a per-command basis.
To toggle case sensitivity for all commands, use the CommandLine::setSubcommandsCaseInsensitive
and CommandLine::setOptionsCaseInsensitive
methods. Use the CommandSpec::subcommandsCaseInsensitive
and CommandSpec::optionsCaseInsensitive
methods to give some commands a different case sensitivity than others.
From this release, when the index = "..."
attribute is omitted, the default index is index = "0+"
, which tells picocli to assign an index automatically, starting from zero, based on the other positional parameters defined in the same command.
A simple example can look like this:
class AutomaticIndex {
@Parameters(hidden = true) // "hidden": don't show this parameter in usage help message
List<String> allParameters; // no "index" attribute: captures _all_ arguments
@Parameters String group; // assigned index = "0"
@Parameters String artifact; // assigned index = "1"
@Parameters String version; // assigned index = "2"
}
Picocli initializes fields with the values at the specified index in the arguments array.
String[] args = { "info.picocli", "picocli", "4.3.0" };
AutomaticIndex auto = CommandLine.populateCommand(new AutomaticIndex(), args);
assert auto.group.equals("info.picocli");
assert auto.artifact.equals("picocli");
assert auto.version.equals("4.3.0");
assert auto.allParameters.equals(Arrays.asList(args));
The default automatic index (index = "0+"
) for single-value positional parameters is "anchored at zero": it starts at zero, and is increased with each additional positional parameter.
Sometimes you want to have indexes assigned automatically from a different starting point than zero. This can be useful when defining Mixins with positional parameters.
To accomplish this, specify an index with the anchor point and a +
character to indicate that picocli should start to automatically assign indexes from that anchor point. For example:
class Anchored {
@Parameters(index = "1+") String p1; // assigned index = "1" or higher
@Parameters(index = "1+") String p2; // assigned index = "2" or higher
}
Finally, sometimes you want to have indexes assigned automatically to come at the end. Again, this can be useful when defining Mixins with positional parameters.
To accomplish this, specify an index with a +
character to indicate that picocli should automatically assign indexes that come at the end. For example:
class Unanchored {
@Parameters(index = "+") String penultimate; // assigned the penultimate index in the command
@Parameters(index = "+") String last; // assigned the last index in the command
}
From this release, positional parameters can be used in repeating Argument Groups.
When a @Parameters
positional parameter is part of a group, its index
is the index within the group, not within the command.
Below is an example of an application that uses a repeating group of positional parameters:
@Command(name = "grades", mixinStandardHelpOptions = true, version = "grades 1.0")
public class Grades implements Runnable {
static class StudentGrade {
@Parameters(index = "0") String name;
@Parameters(index = "1") BigDecimal grade;
}
@ArgGroup(exclusive = false, multiplicity = "1..*")
List<StudentGrade> gradeList;
@Override
public void run() {
gradeList.forEach(e -> System.out.println(e.name + ": " + e.grade));
}
public static void main(String[] args) {
System.exit(new CommandLine(new Grades()).execute(args));
}
}
Running the above program with this input:
Alice 3.1 Betty 4.0 "X Æ A-12" 3.5 Zaphod 3.4
Produces the following output:
Alice: 3.1
Betty: 4.0
X Æ A-12: 3.5
Zaphod: 3.4
@Spec(MIXEE)
AnnotationFrom this release, mixins are more powerful. Mixin classes can declare a @Spec(MIXEE)
-annotated field, and picocli will inject the CommandSpec
of the command receiving this mixin (the "mixee") into this field. This is useful for mixins containing shared logic, in addition to shared options and parameters.
Since picocli 4.3, the @Spec
annotation has a value
element.
The value is Spec.Target.SELF
by default, meaning that the CommandSpec
of the enclosing class is injected into the @Spec
-annotated field.
For classes that are used as a mixins, there is another value that may be useful.
When @Spec(Spec.Target.MIXEE)
is specified in a mixin class, the CommandSpec
of the command receiving this mixin (the "mixee") is injected into the @Spec
-annotated field.
This can be useful when a mixin contains logic that is common to many commands. For example:
import picocli.CommandLine.Option;
import picocli.CommandLine.Spec;
class AdvancedMixin {
@Spec(Spec.Target.MIXEE) CommandSpec mixee;
/**
* When the -x option is specified on any subcommand,
* multiply its value with another integer supplied by this subcommand
* and set the result on the top-level command.
* @param x the value of the -x option
*/
@Option(names = "-x")
void setValue(int x) {
// Get another value from the command we are mixed into.
// This mixin requires the command(s) it is mixed into to implement `IntSupplier`.
int y = ((java.util.function.IntSupplier) mixee.userObject()).getAsInt();
int product = x * y;
// Set the result on the top-level (root) command.
// This mixin requires the root command to implement `IntConsumer`.
((java.util.function.IntConsumer) mixee.root().userObject()).accept(product);
}
}
--
End of Options in usage helpFrom picocli 4.3, an entry for the --
End of Options delimiter can be shown in the options list of the usage help message of a command with the @Command(showEndOfOptionsDelimiterInUsageHelp = true)
annotation.
Example command:
@Command(name = "myapp", showEndOfOptionsDelimiterInUsageHelp = true,
mixinStandardHelpOptions = true, description = "Example command.")
class MyApp {
@Parameters(description = "A file.") File file;
}
The usage help message for this command looks like this:
Usage: myapp [-hV] [--] <file>
Example command.
<file> A file.
-h, --help Show this help message and exit.
-V, --version Print version information and exit.
-- This option can be used to separate command-line options from
the list of positional parameters.
--
in usage help options list.@Spec(Spec.Target.MIXEE)
annotation element to allow mixins to get a reference to the command they are mixed into.CommandSpec::root
to return the CommandSpec
of the top-level command.errors
and stackTraces
to Help.ColorScheme
. Thanks to Neko Null for the pull request.splitSynopsisLabel
attribute on @Option
and @Parameters
for controlling how split
regular expressions are displayed in the synopsis. Thanks to Murphy Han for the pull request and thanks to deining for raising this.-Averbose
annotation processor option to enable printing NOTE-level diagnostic messages to the console.Runnable
or Callable
. Thanks to Max Rydahl Andersen for the suggestion.HelpCommand
. Thanks to NewbieOrange for the pull request.setOptionsCaseInsensitive
should make negatable options case insensitive. Thanks to NewbieOrange for the pull request.@ArgGroup
argument groups in @Command
-annotated methods. Thanks to Usman Saleem for raising this.CommandLine
instances. Thanks to Linyer-qwq, WU Jiangning, and Wycers for the pull request.CommandLine
object is reused. Thanks to marinier for pointing this out.@filename
is the only parameter. Thanks to Wycer for the pull request.NullPointerException
in IParameterConsumer
with @Option
in @ArgGroup
. Thanks to masupilami for raising this.MethodBinding.set
methods should use getTargetException
not getCause
; better error reporting.flush()
in UnmatchedArgumentException.printSuggestions
. Thanks to darkmoonka for raising this.picocli-codegen
annotation processor documentation: disable.resource.config
is correct (the option name was incorrectly spelled as disable.resources.config
). Thanks to Max Rydahl Andersen for raising this.picocli-codegen
annotation processor during the build with Kotlin.TypeConversionException
. Add example InetSocketAddressConverter
to picocli-examples
. Thanks to Simon for raising this.${project.groupId}
instead of deprecated ${groupId}
. Thanks to Dmitry Timofeev for the pull request.picocli-shell-jline3
prior to and after the [#987][#969] bugfix. Thanks to Ralf D. Müller for raising this.split
regex for FIX message example. Thanks to Galder Zamarreño and Max Rydahl Andersen for raising this and subsequent discussion.picocli-examples
, bump hibernate-validator
from 6.0.2 to 6.1.2 to deal with CVE-2019-10219. Thanks to https://github.com/Security3rd for raising this.No features were deprecated in this release.
Behaviour has changed for some cases involving positional parameters.
One example is applications that define multiple positional parameters without an explicit index
(see next section).
I hope these are edge cases.
Other than that, some error messages and details of the usage help message have changed.
See details below.
Prior to picocli 4.3.0, if your application defines any single-value positional parameters without explicit index
, these parameters would all point to index zero.
From picocli 4.3.0, picocli automatically assigns an index, so the first such parameter gets index 0
(zero), the next parameter gets index 1
(one), the next parameter gets index 2
(two), etc.
This may break applications that have multiple single-value positional parameters without explicit index
, that expect to capture the first argument in all of these parameters.
The error message has changed when a user specifies more positional parameters than the program can accept. For example:
class SingleValue {
@Parameters String str;
}
This program only accepts one parameter. What happens when this program is invoked incorrectly with two parameters, like this:
java SingleValue val1 val2
Before this release, picocli would throw an OverwrittenOptionException
with message "positional parameter at index 0..* (<str>) should be specified only once"
.
From picocli 4.3, picocli throws an UnmatchedArgumentException
with message "Unmatched argument at index 1: 'val2'"
.
This may break applications that have error handling that depends on an OverwrittenOptionException
being thrown.
Continuing with the previous example, before this release, applications could deal with this by allowing single-value options to be overwritten:
// before
CommandLine cmd = new CommandLine(new SingleValue());
cmd.setOverwrittenOptionsAllowed(true);
// ...
From picocli 4.3, applications need to allow unmatched arguments instead:
// after
CommandLine cmd = new CommandLine(new SingleValue());
cmd.setUnmatchedArgumentsAllowed(true);
// ...
// get the invalid values
cmd.getUnmatchedArguments();
Before picocli 4.3.0, single-value positional parameters would incorrectly show an ellipsis (...
) after their parameter label. This ellipsis is incorrect because it indicates that multiple values can be specified. The ellipsis is no longer shown for single-value positional parameters from picocli 4.3.0.
Before:
Usage: <main class> PARAM...
PARAM... Param description.
After:
Usage: <main class> PARAM
PARAM Param description.
This may break application tests that expect a specific usage help message format.
Before:
Missing required option '--required=<required>'
Missing required options [-a=<first>, -b=<second>, -c=<third>]
After:
Missing required option: '--required=<required>'
Missing required options: '-a=<first>', '-b=<second>', '-c=<third>'
Before:
Missing required options [-x=<x>, params[0]=<p0>, params[1]=<p1>]
After:
Missing required options and parameters: '-x=<x>', '<p0>', '<p1>'
Before:
Missing required parameter: <mandatory>
Missing required parameters: <mandatory>, <anotherMandatory>
After:
Missing required parameter: '<mandatory>'
Missing required parameters: '<mandatory>', '<anotherMandatory>'
The picocli community is pleased to announce picocli 4.2.0.
This release adds support for Repeatable Subcommands: when a command is marked as @Command(subcommandsRepeatable = true)
it becomes possible to specify that command's subcommands multiple times on the command line.
The picocli-codegen
module can now generate AsciiDoc documentation for picocli-based applications. AsciiDoc is a lightweight markup language that can easily can be converted to unix man pages, HTML and PDF with the wonderful asciidoctor tool.
From this release, subcommands are not instantiated until they are matched on the command line. This should improve the startup time for applications with subcommands that do a lot of initialization when they are instantiated.
Autocompletion improvements: from this release the generated bash completions scripts support completing positional parameters, and are implemented without the use of associative arrays (so they should work on MacOS or other systems that use older versions of bash). Additionally there are now automated tests using Expect to verify that the generated completion scripts work as expected.
GraalVM configuration generation improvement: added --factory
option to ReflectionConfigGenerator
, ResourceConfigGenerator
and DynamicProxyConfigGenerator
. This makes it possible to generate configurations for command classes without a default no-arg constructor.
From this release it is possible to inject the CommandSpec
into a IVersionProvider
, making it easier to write version provider implementations that are reusable across multiple commands or even applications.
Similarly, from this release it is possible to inject the parent command object into mixins via a @ParentCommand
-annotated field.
This release adds programmatic API to allow the long options column to grow larger than 20 characters in the usage help message via the CommandLine::setLongOptionsMaxWidth
and UsageMessageSpec::longOptionsMaxWidth
methods.
Finally, it is now possible let the usage help show that @-files are supported by listing a @<filename>
entry above the list of positional parameters in the usage help.
This is the sixty-seventh public release. Picocli follows semantic versioning.
This release adds a new class picocli.codegen.docgen.manpage.ManPageGenerator
to the picocli-codegen
module that generates AsciiDoc documentation for picocli-based applications using the manpage
doctype and manpage document structure.
The generated AsciiDoc files can be converted to HTML, PDF and unix man pages with the asciidoctor tool.
The picocli-codegen
README has more details.
From picocli 4.2, it is possible to specify that a command's subcommands can be specified multiple times by marking it with @Command(subcommandsRepeatable = true)
.
Below is an example where the top-level command myapp
is marked as subcommandsRepeatable = true
.
This command has three subcommands, add
, list
and send-report
:
@Command(name = "myapp", subcommandsRepeatable = true)
class MyApp implements Runnable {
@Command
void add(@Option(names = "-x") String x, @Option(names = "-w") double w) { ... }
@Command
void list(@Option(names = "--where") String where) { ... }
@Command(name = "send-report")
void sendReport(@Option(names = "--to", split = ",") String[] recipients) { ... }
// ...
}
The above example command allows users to specify one or more of its subcommands multiple time. For example, this would be a valid invocation:
myapp add -x=item1 -w=0.2 \
add -x=item2 -w=0.5 \
add -x=item3 -w=0.7 \
list --where "w>0.2" \
send-report [email protected]
In the above command line invocation, the myapp
top-level command is followed by its subcommand add
. Next, this is followed by another two occurences of add
, followed by list
and send-report
. These are all "sibling" commands, that share the same parent command myapp
. This invocation is valid because myapp
is marked with subcommandsRepeatable = true
.
Normally, subcommandsRepeatable
is false
, so for each command, only one of its subcommands can be specified, potentially followed by only one sub-subcommand of that subcommand, etc.
In mathematical terms, a valid sequence of commands and subcommands can be represented by a directed rooted tree that starts at the top-level command. This is illustrated by the diagram below.
When subcommandsRepeatable
is set to true
on a command, the subcommands of this command may appear multiple times.
Also, a subcommand can be followed by a "sibling" command (another command with the same parent command).
In mathematical terms, when a parent command has this property, the additional valid sequences of its subcommands form a fully connected subgraph (a complete digraph).
The blue and green dotted arrows in the diagram below illustrate the additional sequences that are allowed when a command has repeatable subcommands.
Note that it is not valid to specify a subcommand followed by its parent command:
# invalid: cannot move _up_ the hierarchy
myapp add -x=item1 -w=0.2 myapp
From this release, subcommands are not instantiated until they are matched on the command line,
unless the user object has a @Spec
or @ParentObject
-annotated field; these are instantiated during initialization.
CommandSpec
Into a IVersionProvider
From this release, IVersionProvider
implementations can have @Spec
-annotated fields. If such a field
exists, picocli will inject the CommandSpec
of the command that uses this version provider. This gives the version provider access to the full command hierarchy, and may make it easier to implement version providers that can be reused among multiple commands.
For example:
class MyVersionProvider implements IVersionProvider {
@Spec CommandSpec spec;
public String[] getVersion() {
return new String[] { "Version info for " + spec.qualifiedName() };
}
}
@filename
in usage helpFrom picocli 4.2, an entry for @<filename>
can be shown in the options and parameters list of the usage help message of a command with the @Command(showAtFileInUsageHelp = true)
annotation.
Example:
@Command(name = "myapp", showAtFileInUsageHelp = true,
mixinStandardHelpOptions = true, description = "Example command.")
class MyApp {
@Parameters(description = "A file.") File file;
}
The usage help message for this command looks like this:
Usage: myapp [-hV] [@<filename>...] <file>
Example command.
[@<filename>...] One or more argument files containing options.
<file> A file.
-h, --help Show this help message and exit.
-V, --version Print version information and exit.
By default, the @<filename>
entry is shown before the positional parameters in the synopsis as well as in the parameters list. This can be changed with the Help API for reordering sections.
Both the label and the description of the @<filename>
entry have been defined with custom variables, to allow applications to change the text. The variables are:
picocli.atfile.label
picocli.atfile.description
By setting the above variables in either system properties, environment variables or the resource bundle for a command, the text can be customized.
See the user manual for examples.
@ParentCommand
-annotated fieldsA common use case is sharing options between different levels of the command hierarchy, so that "global" options from the top-level command are also available on subcommands.
Since picocli 4.2, @ParentCommand
-annotated fields can be used in mixins, which makes this easier. See the Use Case: Sharing Options section of the user manual for a full example.
For mixins that need to be reusable across more than two levels in the command hierarchy, injecting a @Spec
-annotated field gives the mixin access to the full command hierarchy.
The default layout shows short options and long options in separate columns, followed by the description column. The width of the long options column shrinks automatically if all long options are very short, but by default this column does not grow larger than 20 characters.
If the long option with its option parameter is longer than 20 characters (for example: --output=<outputFolder>
), the long option overflows into the description column, and the option description is shown on the next line.
This (the default) looks like this:
Usage: myapp [-hV] [-o=<outputFolder>]
-h, --help Show this help message and exit.
-o, --output=<outputFolder>
Output location full path.
-V, --version Print version information and exit.
From picocli 4.2, there is programmatic API to change this via the CommandLine::setLongOptionsMaxWidth
and UsageMessageSpec::longOptionsMaxWidth
methods.
In the above example, if we call commandLine.setLongOptionsMaxWidth(23)
before printing the usage help, we get this result:
Usage: myapp [-hV] [-o=<outputFolder>]
-h, --help Show this help message and exit.
-o, --output=<outputFolder> Output location full path.
-V, --version Print version information and exit.
@Spec CommandSpec spec
into IVersionProvider
implementations. Thanks to Garret Wilson for raising this.@Command(showAtFileInUsageHelp=true)
attribute to show @filename
in usage help.@ParentCommand
-annotated fields in mixin classes.Help.subcommands()
method from protected to public.picocli-codegen
module can now generate AsciiDoc documentation that uses the manpage
doctype and adheres to the manpage document structure so it can be converted to unix man pages in troff format with the asciidoctor tool.picocli.codegen.docgen.manpage.ManPageGenerator
to the picocli-codegen
module that generates AsciiDoc documentation using the manpage
doctype and manpage document structure.
Custom markup like @|bold mytext|@
, @|italic mytext|@
etc., originally intended to be converted to ANSI escape codes, can from this release also be converted to custom markup like <b>mytext</b>
and <i>mytext</i>
in HTML, or *mytext*
and _mytext_
in lightweight markup languages like AsciiDoc.
Applications can control this by setting a ColorScheme
with a custom markup map.
This ticket resulted in the following additional methods: ColorScheme::text
, ColorScheme::string
, ColorScheme::customMarkupMap
, ColorScheme::parse
, ColorScheme::resetStyle
, ColorScheme::apply
, ColorScheme.Builder::customMarkupMap
(getter and setter) and a new picocli.CommandLine.Help.Ansi.Text(String, ColorScheme)
constructor.
The picocli.CommandLine.Help.Ansi::apply
method is now deprecated in favor of ColorScheme::apply
.--factory
option to ReflectionConfigGenerator
, ResourceConfigGenerator
and DynamicProxyConfigGenerator
. Thanks to Santiago Acosta for raising this.DEBUG
tracing noise if no resource bundle is set.--exit
option to picocli codegen utilities.NullPointerException
during initialization.@Command
-annotated methods without arguments caused a IllegalAccessException
. From this release such methods no longer need to be public. Thanks to David Connelly for raising this.CommandSpec.mixinAnnotatedElements
map should be initialized when discovering @Mixin
-annotated fields and methods via reflection.Text.getStyledChars
no longer incorrectly inserts ANSI escape chars into the next line prefix when lines are broken.Text.substring
now leaves out StyledSection
instances that do not apply.ResourceBundle
to internationalize and localize your CLI app. Thanks to Andreas Deininger for the pull request.picocli.CommandLine.Help.Ansi#apply
method has been deprecated in favor of the picocli.CommandLine.Help.ColorScheme#apply
method.picocli.CommandLine.Help.TextTable forDefaultColumns(Ansi, int, int)
method has been deprecated in favor of the new TextTable.forDefaultColumns(ColorScheme, int, int)
method.picocli.CommandLine.Help.TextTable forColumnWidths(Ansi, int...)
method has been deprecated in favor of the new TextTable.forColumnWidths(ColorScheme, int...)
method.picocli.CommandLine.Help.TextTable forColumns(Ansi, Column...)
method has been deprecated in favor of the new TextTable.forColumns(ColorScheme, Column...)
method.picocli.CommandLine.Help.TextTable constructor (Ansi, Column[])
has been deprecated in favor of the new TextTable(ColorScheme, Column...)
constructor.Annotated command objects are now not instantiated until the command is matched on the command line.
Previously all subcommands were instantiated when the top-level command's CommandLine
was constructed.
The picocli community is pleased to announce picocli 4.1.4.
This release contains a bugfix for GraalVM users, and minor documentation enhancements.
This release fixes a bug in the picocli-codegen
annotation processor that generates an incorrect reflect-config.json
file with invalid entries for inner classes of commands in the unnamed package, that are unnecessarily prefixed with a dot. This makes the GraalVM native-image
generator fail with an error like "Class .Outer$Inner not found".
This is the sixty-sixth public release. Picocli follows semantic versioning.
picocli-codegen
generates invalid reflect-config.json for classes in unnamed package.CommandLine.invoke()
function. Thanks to Andreas Deininger for the pull request.No features were deprecated in this release.
This release has no breaking changes.
The picocli community is pleased to announce picocli 4.1.3.
This release contains a bugfix for GraalVM users.
This release fixes a bug in the picocli-codegen
annotation processor that generates an incorrect reflect-config.json
file with duplicate entries for inner classes of a command, one with the standard class name and one with the canonical class name. This makes the GraalVM native-image
generator fail with an error like "Class Outer.Inner not found".
This is the sixty-fifth public release. Picocli follows semantic versioning.
picocli-codegen
generated invalid reflect-config.json for inner classes.No features were deprecated in this release.
This release has no breaking changes.