picocli | Picocli is a modern framework for building powerful, user-friendly, GraalVM-enabled command line app | Parser library
kandi X-RAY | picocli Summary
kandi X-RAY | picocli Summary
Picocli aims to be the easiest-to-use way to create rich command line applications that can run on and off the JVM. Considering picocli? Check what happy users say about picocli. Picocli is a modern library and framework, written in Java, that contains both an annotations API and a programmatic API. It features usage help with ANSI colors and styles, TAB autocompletion and nested subcommands. In a single file, so you can include it in source form. This lets users run picocli-based applications without requiring picocli as an external dependency. Picocli-based applications can be ahead-of-time compiled to a native image, with extremely fast startup time and lower memory requirements, which can be distributed as a single executable file. Picocli comes with an annotation processor that automatically Graal-enables your jar during compilation. Picocli applications can be very compact with no boilerplate code: your command (or subcommand) can be executed with a single line of code. Simply implement Runnable or Callable, or put the business logic of your command in a @Command-annotated method. Picocli makes it easy to follow Command Line Interface Guidelines. How it works: annotate your class and picocli initializes it from the command line arguments, converting the input to strongly typed data. Supports git-like subcommands (and nested sub-subcommands), any option prefix style, POSIX-style grouped short options, custom type converters, password options and more. Picocli distinguishes between named options and positional parameters and allows both to be strongly typed. Multi-valued fields can specify an exact number of parameters or a range (e.g., 0..*, 1..2). Supports Map options like -Dkey1=val1 -Dkey2=val2, where both key and value can be strongly typed. Parser tracing facilitates troubleshooting. Command-line argument files (@-files) allow applications to handle very long command lines. Generates polished and easily tailored usage help and version help, using ANSI colors where possible. Requires at minimum Java 5, but is designed to facilitate the use of Java 8 lambdas. Tested on all Java versions between 5 and 18-ea (inclusive). Picocli-based command line applications can have TAB autocompletion, interactively showing users what options and subcommands are available. When an option has completionCandidates or has an enum type, autocompletion can also suggest option values. Picocli can generate completion scripts for bash and zsh, and offers picocli-shell-jline2 and picocli-shell-jline3 modules with JLine Completer implementations for building interactive shell applications. Unique features in picocli include support for negatable options, advanced quoted values, and argument groups. Argument groups can be used to create mutually exclusive options, mutually dependent options, option sections in the usage help message and repeating composite arguments like ([-a= -b= -c=] (-x | -y | -z)).... For advanced use cases, applications can access the picocli command object model with the @Spec annotation, and implement custom parameter processing for option parameters if the built-in logic is insufficient. Picocli-based applications can easily integrate with Dependency Injection containers. The Micronaut microservices framework has built-in support for picocli. Picocli ships with a picocli-spring-boot-starter module that includes a PicocliSpringFactory and Spring Boot auto-configuration to use Spring dependency injection in your picocli command line application. The user manual has examples of integrating with Guice, Spring Boot, Micronaut, Quarkus and with containers that comply to CDI 2.0 specification (JSR 365).
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- This method applies a value to a single valued field .
- Generate a function for the given command and command line .
- Executes user object
- Create the custom usage help factory .
- Generates the options .
- Modify base script type .
- Build options and positions from method parameters .
- Create the synopsis text for the options .
- Split a string into chunks .
- Returns an array of textual descriptions for the given option .
picocli Key Features
picocli Examples and Code Snippets
Lines of Code : 64License : Strong Copyleft (CC BY-SA 4.0)
Copy@Command
public class CMD implements Runnable {
@Parameters
private String x;
@ArgGroup(exclusive = false)
private Group group = new Group();
static class Group {
@Option(names = "-a", required = true, deimport picocli.CommandLine.PropertiesDefaultProvider;
@Command(name = "myapp", defaultValueProvider = PropertiesDefaultProvider.class)
class MyApp { }
class MyApp {
@Option(names = "-D")
void setSystemPro@Command(name = "taker-mvo-2", mixinStandardHelpOptions = true, version = "taker-mvo-2 0.2")
class TakerMvo2 implements Runnable {
// ...
@Option(names = {"-C", "--credential"}, description = "credential file")
File file;
Usage: app [-hV] [-A [-B]]
app [-hV] [-A [-A1] [-A2] [-A3]]
import picocli.CommandLine;
import picocli.CommandLine.*;
import picocli.CommandLine.Model.CommandSpec;
@Command(name = "app", mixinStandardHelpOpCommandLine.run(callable, args); // internally uses RunLast, equivalent to:
new CommandLine(callable).parseWithHandler(new RunLast(), args);
public static void main(String[] args) {
args = new String[] { "--ve @CommandLine.Command
public String sayGoodbye()
{
return printValue("GoodBye");
}
// extend RunLast to handle requests for help/version and exit code stuff
class PrintingExecutionStrategy exIndex: jsoar-core/src/main/java/org/jsoar/kernel/commands/LogCommand.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--@Command
class ExitCodeDemo implements Callable {
@Parameters(index = "0", description = "manifest")
private File manifest;
public Integer call() {
// business logic here
return ok ? 0 : 123;
}
public Community Discussions
Trending Discussions on picocli
QUESTION
A tool I am currently working on has a lot of subcommands which makes picocli's help output unclear. My code looks like this:
...ANSWER
Answered 2022-Apr-08 at 02:49Yes that is possible by diving under the hood of picocli's Help API.
One idea is to have a custom IHelpSectionRenderer, see this example: https://github.com/remkop/picocli/blob/main/picocli-examples/src/main/java/picocli/examples/customhelp/GroupingDemo.java
QUESTION
I have successfully ported my desktop application from Dagger/Spring to Micronaut/Spring (there's just way too much Spring code in there for me to be able strip it all out in a timely manner). Using Micronaut and PicoCLI everything is working beautifully in Eclipse/Gradle. It's launching, tests are passing, so now I want to do a build and install it to make sure that everything will work for our customer.
Our build (via Gradle) uses Shadow (com.github.johnrengelman.shadow) to combine our application with all of its dependencies into a single Jar file. I've checked and all expected dependencies appear to be present, and from the look of it the generated Micronaut classes are also present in the shadow jar. We then use Launch4J to make this shadow jar executable. From everything that I can tell, the output from Launch4J looks to be correct, however when I try to run the installed application, the splash screen appears for a fraction of a second and that's it. When I run the Launch4J generated executable as a jar file, I get the following:
...ANSWER
Answered 2022-Mar-30 at 13:25I haven't been able to find any information for using launch4j with more than 65535 files (i.e.: something like the shadowJar zip64 flag), nor really much of any information in this regard in general for that matter. However one solution that works for me, is to set dontWrapJar to true. This creates a tiny launcher for running the created jar file with the bundled JRE, rather than converting the entire jar, keeping all (or at least the majority of) the files out of the launch4j generated executable. The updated gradle task is as follows
QUESTION
Write cmd interface with Java code used picocli v4.6.3
My case: ./cmd [-a -b [-c]]
user put a,b option or got default value example:
- user only put: ./cmd x1
a,b,c option got default value
- ./cmd x1 -a=a1
request input b option and vice versa (c option still get default value)
- ./cmd x1 -c=c1
a & b option get default value
ANSWER
Answered 2022-Mar-16 at 05:55Original Answer
The picocli user manual has a detailed section on assigning default values in argument groups.
Applications need to do both of the below:
- specify default values in both the
@Optionannotation, and in the initial value of the@Option-annotated field. (Yes, that means some duplication.) - manually instantiate the
@ArgGroup-annotated field
For your example, that means:
QUESTION
I'm currently using picocli 4.7.0-SNAPSHOT to great effect in a Java 11 application that has a complex set of options, so I am making use of the @-file functionality.
What I am trying to get to work is an option specified directly on the command line to override the same option if it exists in the @-file. So options specified on the command line take precedence over the @-file. Is that possible.
When I try to run my test application, heavily based on the picocli example, with both a command line option and an @-file, I get the following error from picocli along with the expected usage:
...ANSWER
Answered 2022-Mar-16 at 04:59Let me paraphrase the question to see if I understand it correctly:
If the end user specifies an option directly on the command line, the command line value should be used, while if that option is not specified on the command line, the value in a file should be used.
Essentially, you are using an @-file with the intention to define default values for one or more options. However, that is not what @-files were designed for: picocli cannot distinguish between arguments that came from the command line and arguments that came from the @-file.
I would suggest using picocli's default provider mechanism instead.
One idea is to use the built-in PropertiesDefaultProvider:
QUESTION
My PicoCLI-based application has multiple commands and sub-commands with general options that apply to all commands, and some options which apply to the specific command. The general options are used for all the commands.
My PicoCLI (sub-)commands are similar to this example:
...ANSWER
Answered 2022-Feb-22 at 02:16One idea is to use a custom Execution Strategy.
The Initialization Before Execution section of the picocli user manual has an example. Let's try to modify that example for your use case. I arrive at something like this:
QUESTION
I've built a Quarkus 2.7.1 console application using picocli that includes several subcommands. I'd like to be able to run this application within a Kubernetes cluster and decide its arguments at run-time. This is so that I can use the same container image to run the application in different modes within the cluster.
To get things started I added the JIB extension and tried setting the arguments using a configuration value quarkus.jib.jvm-arguments. Unfortunately it seems like this configuration value is locked at build-time so I'm unable to update this at run-time.
Next I tried setting quarkus.args while using default settings for JIB. The configuration value documentation makes it sound general enough for the job but it doesn't seem to have an affect when the application is run in the container. Since most references to this configuration value in documentation are in the context of Dev Mode I'm wondering if this may be disabled outside of that.
How can I get this application running in a container image with its arguments decided at run-time?
...ANSWER
Answered 2022-Feb-16 at 16:11I was able to find a solution to the problem with a bit of experimenting this morning.
With the quarkus-container-image-docker extension (instead of quarkus.jib.jvm-arguments) I was able to take the template Dockerfile.jvm and extend it to pass through arguments to the CLI. The only line that needed changing was the ENTRYPOINT (details included in the snippet below). I changed the ENTRYPOINT form (from exec to shell) and added an environment variable as an argument to pass-through program arguments.
QUESTION
My program uses Picocli to parse XML data and store it in an ArrayList. For some reason, the information gets removed when I try to access it from another class.
I run the code below, and it shows the elements just fine:
...ANSWER
Answered 2022-Feb-21 at 13:51The static context of the SourceSentences.main() is lost once you run the getArrayElements.main() method. The parsing of your XML data never happened as far as getArrayElements.main() was concerned.
You need to call the translate method from inside the getArrayElements' main function.
QUESTION
I have a Java application that has a GUI made with Swing and that uses two databases interchangeably. One of the two databases is mongoDB and the other one is MySQL. Which database to use is chosen with a command line option. For the MySQL database I am also using Hibernate and JPA. The code I have looks like this:
...ANSWER
Answered 2022-Feb-14 at 11:37Short answer, yes, it should be closed. And the reason can be found at this answer:
The JVM will release all active resources upon termination; however, this does not ensure that the other end will free the resource too, so explicitly closing resources is in every programmer's best interest.
So in my case, it is true that the EntityManager and factory are closed at application shutdown, but this does not ensure that they are properly dealt with on the other end. I didn't mention it in my question, but in fact the same thing holds true for the Mongo Client as well (see this answer):
If you ever re-deploy your web application without first restarting your application server, you must ensure that the MongoClient is closed when your web application is shutdown.
About the implementation I made an interface that I called DBInitializer. I instantiated an object of type MongoInitializer or MySQLInitializer (both implementing DBInitializer) inside the main method. See code for more clarity.
DBInitializer:
QUESTION
I mimic code snippet at reference document at https://groovy-lang.org/syntax.html#_groovydoc_comment
Program
...ANSWER
Answered 2022-Feb-10 at 02:28Thank @tim_yates, Set VM option
QUESTION
I am running a Micronaut CLI application via Picocli runner wanted to use applicationContext for injecting/getting the bean during application execution.
...ANSWER
Answered 2022-Feb-07 at 21:08The property needs to be in the AuthenticationFilter class. That class should be annotated with jakarta.inject.Singleton and should not be private
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install picocli
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page
