Re: [cli]

[Remko Popma]

You are correct.
With Commons Cli you will have to write a custom HelpFormatter to provide
end users with more detail about the positional parameters.

You may be interested in https://picocli.info/ which provides this
functionality out of the box, along with colored help, autocomplete and
support for easily turning your CLIs into native binaries.
(Disclaimer: I wrote it.) Enjoy!


On Thu, Jan 13, 2022 at 8:50 AM Charles Johnson 
wrote:

> Given the standard format of
>
> progam [options] 
>
> I am confused how Commons Cli treats the last above. Obviously
> CommandLine.getArgList will get that argument. But that doesn't help me
> when it comes to HelpFomatter. That seems only to know about Options. Am
> I to understand that the Option class has to be used for arguments too,
> if I want to tell the user about ?
>
> TIA
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

Re: [cli]

[Remko Popma]

Hi tobias,

You may want to take a look at picocli .
Picocli is a modern library with support for mutually exclusive options
 and more, like
subcommands, TAB completion, colored usage help, and allows easy
compilation to a GraalVM native image, so you can distribute your CLI as a
single executable file.

I maintain picocli, so I am of course very very biased. :-)

Based on this mailing list, I do not see much interest in the Commons
community in working on commons-cli or commons-cli2, but I could be wrong.





On Thu, Mar 18, 2021 at 5:01 PM  wrote:

> Is there a possibility to use mutual exklusive arguments like e.g.
>
>
>
> myapp --info regid  | email 
>
> --info --> command
>
> --regid --> first argument
>
> --email --> second argument
>
>
>
> Both argument are mutual exclusive!
>
> How to do this with cli?
>
> Are there any plans to release cli2?
>
> In cli2 it's possibe to create more complex arguments, right?
>
>
>
>

Re: Apache Commons CLI default value of Option

[Remko Popma]

May I recommend using the picocli  library instead?
Picocli has more functionality than any other CLI library, has excellent
documentation, and is actively maintained.

Using picocli's annotation API, one way to accomplish your use case would
be like the example below.
(There is also a programmatic API.)

class MyApp implements Runnable /*Callable is fine too*/ {

  @Option(names = {"--my-opt"}, paramLabel = "my-opt", defaultValue = "XX",
   description = "Some help. Default value is ${DEFAULT-VALUE}.")
  String myOpt;

  public void run() {
// business logic here
  }

  public static void main(String[] args) {
System.exit(new CommandLine(new MyApp()).execute(args));
  }
}

On Fri, Nov 6, 2020 at 8:50 PM Flavio Pompermaier 
wrote:

> Hi to all,
> I was trying to use your library to parse the arguments passed from the
> command line and I have 2 questions/1 observation: why the Option doesn't
> have a default value but the default value is handled by the CommandLine?
> Currently you have to use CommandLine.getValue(defaultValue) but this has
> one big limitation to me, i.e. you can't print the default value in the
> help (assuming to use HelpFormatter). Am I wrong?
> I think that also the code would benefit from moving the default value in
> the Option (since you better separate the concerns). for example:
>
> public static Option getDatalinksJobIdOption() {
> return Option.builder("someOpt")
> .argName("my-opt")
> .type(String.class)
> .hasArg(true)
> .desc("Some help")
> -defaultValue("XX")
> .build();
>   }
>
> What do you think?
>
> Best,
> Flavio
>

Re: Quoted content

[Remko Popma]

Also check out https://github.com/osiegmar/FastCSV

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jun 14, 2019, at 23:53, Gary Gregory  wrote:
> 
> I've never like mashing formatting and parsing options together. Should we
> have CSVFormat subclasses called CSVPrintingFormat and CSVParsingFormat?
> 
> Gary
> 
> On Fri, Jun 14, 2019 at 10:24 AM Daryl Stultz 
> wrote:
> 
>> 
>> 
>>> withIgnoreSurroundingSpaces() affects parsing
>>> withTrim() affects printing.
>> 
>> Ah, that is exactly what I needed, withIgnoreSurroundingSpaces() solves my
>> problem. (Definitely hard to understand that which applies to parsing and
>> that which applies to printing!)
>> 
>> Thank you so much.
>> 
>> /Daryl
>> 
>> 
>> 

Re: org.apache.commons.lang3.time.StopWatch resolution

[Remko Popma]

Timers and elapsed time in Java is an interesting topic. Can be a moving target 
though...

Some recent articles:
https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking/

https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking-part-ii-windows/

Remko.

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jun 7, 2019, at 6:13, Gary Gregory  wrote:
> 
> The OS' clock resolution is in play here, which depending on your OS will
> give you varying results. Also, on Java 9, you get better clock resolution
> for certain APIs. Kinda messy...
> 
> Gary
> 
> On Thu, Jun 6, 2019 at 4:28 PM Erwin Hogeweg 
> wrote:
> 
>> Hi,
>> 
>> I am tad confused about the StopWatch resolution. I have a very basic
>> JUnit test that starts a stopwatch, wait for 10ms and then stops it, and
>> checks the value. In about 40% of the cases it is less than the 10ms wait
>> time.
>> 
>> Is that expected? What is my blind spot?
>> 
>> 
>> Regards,
>> 
>> Erwin
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>> 
>> 

Re: [dbutils]

[Remko Popma]

Is there really a need to rewrite Spock tests to another testing framework?

Remko.

(Shameless plug) Every java main() method deserves http://picocli.info

> On Mar 7, 2019, at 6:25, Gary Gregory  wrote:
> 
> Robert,
> 
> This seems like a fine addition to DbUtils. I'd love to see a PR on GitHub.
> Adding more documentation would be nice. WRT bringing this into DbUtils,
> can we avoid adding a new interface by using Java 8 default methods
> on QueryRunner? If DbUtils is not on Java 8, we can bring it up to Java 8.
> 
> Gary
> 
> On Wed, Mar 6, 2019 at 1:05 PM Robert Huffman 
> wrote:
> 
>> I like DbUtils QueryRunner, but the thing that has always bothered me is
>> that it forces me to read the entire ResultSet into memory rather than
>> allowing me to use cursors. So I developed a little library to do that,
>> which I called dbstream, which is on GitHub:
>> https://github.com/rhuffman/dbstream/
>> 
>> It provides an abstract StreamingResultSetHandler that will return a
>> Stream, which each element is built from one row of the query. It
>> utilizes cursors by keeping the ResultSet (and underlying Connection) open
>> until the Stream is closed. There are three concrete subclasses of the
>> handler:
>> 
>>   - ArrayStreamingHandler: returns a Stream, where each Object[]
>>   is the values from a row of the result
>>   - ObjectStreamingHandler: returns a Stream, where each object is
>>   a bean built from a row of the result
>>   - MapStreamingHandler: returns a Stream>, where each
>>   object is a map of column names and values built from a row of the
>> result
>> 
>> Of course, the QueryRunner.query methods close their database objects
>> before returning, so I needed different query methods to execute the query.
>> I extended QueryRunner to create StreamingQueryRunner with these two
>> methods:
>> 
>>   - public  Stream queryAsStream(
>>   String sql,
>>   StreamingResultSetHandler handler,
>>   Object... args)
>> 
>>   - public  Stream queryAsStream(
>>   Connection connection,
>>   String sql,
>>   StreamingResultSetHandler handler,
>>   Object... args)
>> 
>> 
>> I'm probably going to publish it to Maven Central. However, would the
>> DbUtils developers be amenable to doing something like this directly in
>> DbUtils? I could integrate the work into DbUtils and give you a pull
>> request. It might take me a bit because I would have to convert the tests
>> from Spock, but it wouldn't be too bad.
>> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [commons-cli] handling properties files as default . . .

[Remko Popma]

Picocli's value proposition is that it eliminates boilerplate code from the
application.
This allows users to build powerful command line applications with a
minimum of code.

For example:

@Command(name = "demo", mixinStandardHelpOptions = true,
description = "Demonstrate parsing & type conversion")
public class SimpleDemo implements Runnable {

@Option(names = "-x", description = "Print count. ${DEFAULT-VALUE}
by default.")
private int x;

@Option(names = "-d") private double d;
@Option(names = { "-u", "--timeUnit"}) private TimeUnit unit;


@Override
public void run() {
for (int i = 0; i < x; i++) {
System.out.printf("You selected %f, %s.%n", d, unit);
}
}

public static void main(String[] args) {
CommandLine.run(new SimpleDemo(), args);
}
}

If you call this program with command line arguments
-x 3 -d 1.23 -u MINUTES
it will print the following:
You selected 1.23, MINUTES.
You selected 1.23, MINUTES.
You selected 1.23, MINUTES.

With a minimum of code this program defines a set of options, parses the
command line parameters, converts the string values to strongly typed
values, and makes the command line options values available in the
annotated fields. Error handling and help requests are handled in the
CommandLine.run method. There is no need for any Map-like processing any
more, this is all pushed into the library.

(Note that in addition to the annotations API there is also a programmatic
API - similar to the Commons CLI API - which is useful for programs that
dynamically define options. An example of such a program is Groovy's
CliBuilder, which migrated to picocli recently.)

The mixinStandardHelpOptions annotation adds --help and --version options,
so if you call this program with command line argument
--help
it will print the following:

Usage: demo [-hV] [-d=] [-u=] [-x=]
Demonstrate parsing & type conversion
  -d=
  -h, --help  Show this help message and exit.
  -u, --timeUnit=
  -V, --version   Print version information and exit.
  -x=  Print count. 0 by default.

The @Command annotation allows you to plug in a default provider:

@Command(name = "demo", mixinStandardHelpOptions = true,
description = "Demonstrate parsing & type conversion",
defaultValueProvider = PropertyDefaultProvider.class)
public class SimpleDemo implements Runnable { // ...


An example default value provider that reads a properties file could look
like the below.
This does not take care of the encoding requirement you mentioned, but
should be straightforward to extend to meet your requirements:

class PropertyDefaultProvider implements IDefaultValueProvider {
private Properties properties;

@Override
public String defaultValue(ArgSpec argSpec) throws Exception {
if (properties == null) {
properties = new Properties();
File file = new File(System.getProperty("user.dir"),
"defaults.properties");
try (Reader reader = new FileReader(file)) {
properties.load(reader);
}
}
return argSpec.isOption()
? properties.getProperty(((OptionSpec) argSpec).longestName())
: properties.getProperty(argSpec.paramLabel());
}
}

I hope this clarifies a bit.


On Mon, Feb 11, 2019 at 7:30 AM Albretch Mueller  wrote:

> On 2/10/19, P. Ottlinger  wrote:
> > Another way to help out (from the ASF universe) would be:
> > https://tamaya.apache.org/
>
>  I did take a look at tamaya:
>
>  https://tamaya.apache.org/features.html
> ~
>  To me having to go:
>
>  Configuration config = Configuration.builder()
>   .withDefaultPropertySources()
>   .addPropertySources(new MyCustomPropertySource())
>   .withDefaultConverters()
>   .build();
>
>  is a nonsensical and wasteful overkill. What is this useful for,
> exactly? Are there actual use cases that kind of coding relates to?
> ~
> On 2/9/19, Remko Popma  wrote:
> > Picocli has a pluggable default provider
> > (https://picocli.info/#_default_provider), so it should be fairly
> > straightforward to implement what you describe.
>
>  I also spent some time taking a look at picocli and it seems to me
> like some other kind of an overkill:
>
>  13.1. Registering Subcommands Programmatically
>  Subcommands can be registered with the CommandLine.addSubcommand
> method. You pass in the name of the command and the annotated object
> to populate with the subcommand options. The specified name is used by
> the parser to recognize subcommands in the command line arguments.
>
>  CommandLine commandLine = new CommandLine(new Git())
> 

Re: [commons-cli] handling properties files as default . . .

[Remko Popma]

I’m under the impression that Commons-CLI is not under active development any 
more (anyone on the list, feel free to correct me if I’m wrong). 

I would recommend that you take a look at picocli 
(https://github.com/remkop/picocli). Disclosure: I’m the author.)

Picocli has a pluggable default provider 
(https://picocli.info/#_default_provider), so it should be fairly 
straightforward to implement what you describe. 

It also has other nice features that you might be interested in, like usage 
help with ANSI colors, autocompletion, support for subcommands and much more. 

Please take a look. 
Happy to help if any issues pop up. 

Remko.

(Shameless plug) Every java main() method deserves http://picocli.info

> On Feb 10, 2019, at 10:05, Albretch Mueller  wrote:
> 
> of course, the properties file would be the one describing the data,
> even if the command line arguments would take precedence
> 
> lbrtchx
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>