You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Albretch Mueller <lb...@gmail.com> on 2019/02/10 00:51:42 UTC
[commons-cli] handling properties files as default . . .
I was looking into commons-cli, but could not find a few features
which I very much need, basically:
1) there should be a way to use a default properties file in a well
known location (right in "user.dir")
2) that property file should include as part of their metadata
(easiest, right in its name) the encoding used to read the name-value
pairs of properties included in it
3) if user wants she can enter cli parameters in the command line
explicitly and those values would take precedence over the ones in the
properties file
4) user should get a name-value(s) <String><String[]> hashmap. if
there is a parameter for which no value is defined (just the name says
it all) the value would be set to null (user should then deal with the
data herself)
5) the encoding of the properties file and cli would be based on the
metasyntax notations used by the extended Backus Naur form (ISO/IEC
14977)
https://en.wikipedia.org/wiki/Extended_Backus–Naur_form
commons-cli doesn’t seem to be it. Do you know of such a thing (or a
similar one)?
lbrtchx
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Fwd: [commons-cli] handling properties files as default . . .
Posted by "P. Ottlinger" <po...@apache.org>.
Hi,
I tried to inform a possibly interested user about Tamaya and got this
as a response ..... not as friendly as expected :-(
Just fyi
Phil
-------- Weitergeleitete Nachricht --------
Betreff: Re: [commons-cli] handling properties files as default . . .
Datum: Sun, 10 Feb 2019 17:30:26 -0500
Von: Albretch Mueller <lb...@gmail.com>
Antwort an: Commons Users List <us...@commons.apache.org>
An: Commons Users List <us...@commons.apache.org>
On 2/10/19, P. Ottlinger <po...@apache.org> 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 <re...@gmail.com> 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())
.addSubcommand("status", new GitStatus())
.addSubcommand("commit", new GitCommit())
.addSubcommand("add", new GitAdd())
.addSubcommand("branch", new GitBranch())
.addSubcommand("checkout", new GitCheckout())
.addSubcommand("clone", new GitClone())
.addSubcommand("diff", new GitDiff())
.addSubcommand("merge", new GitMerge())
.addSubcommand("push", new GitPush())
.addSubcommand("rebase", new GitRebase())
.addSubcommand("tag", new GitTag());
It is strongly recommended that subcommands have a @Command
annotation with name and description attributes.
~
> It also has other nice features that you might be interested in, like usage
> help with ANSI colors, ... and much
> more.
Does it come with ANSI colors? Will it also dance the macarena for me?
I can't even get what is the point of going through such hoops, when,
to me, all you need is for a HashMap<String><String[]> to be returned
to you. Users shouldn’t be forced to enter command line arguments in a
strict way and order and they should be able to chose the character
encoding of the data they will be feeding into a program (you can’t
expect for every text on a corpus to be encoded as ASCII or UTF-8).To
me this is all there should be to such an utility.
Command line arguments are interpreted as strings in the local
character encoding anyway, right? You would take it from there,
interpreting those sequences of characters with whichever semantics
your code needs to define:
HashMap<String, String[]> HMSSAr ...
String[] aIVal00 = HMSSAr.get("--int-val00");
int iVal00 = (new Integer(aVal00[0])).intValue();
String[] aLVal02 = HMSSAr.get("--long-val02");
long lVal02 = (new Integer(aLVal02[0])).longValue();
String[] aSAr = HMSSAr.get("--strings-ar00");
KCommandObjects KCObjs = new KcommandObjects[aSAr.length];
HashMap<String, Integer> HMSI = new HashMap<String, Integer>();
for(int k = 0; (k < aSAr.length) ;++k){
HMSI.put(aSAr[k], k);
KCObjs[k] = Class.forname(aSAr[k]).newInstance();
}// k [0, aSAr.length)
. . .
I am half way into finishing such a thing, which I thought someone
must had done already. Then I will try to integrate with commons-cli
or put it out there.
I would like to still understand why is it that there exist so many
libraries which complicate such matters and why is it that java itself
doesn't offer a basic option like the one I have described.
lbrtchx
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [commons-cli] handling properties files as default . . .
Posted by sebb <se...@gmail.com>.
On Sun, 10 Feb 2019 at 22:30, Albretch Mueller <lb...@gmail.com> wrote:
>
> On 2/10/19, P. Ottlinger <po...@apache.org> 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 <re...@gmail.com> 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())
> .addSubcommand("status", new GitStatus())
> .addSubcommand("commit", new GitCommit())
> .addSubcommand("add", new GitAdd())
> .addSubcommand("branch", new GitBranch())
> .addSubcommand("checkout", new GitCheckout())
> .addSubcommand("clone", new GitClone())
> .addSubcommand("diff", new GitDiff())
> .addSubcommand("merge", new GitMerge())
> .addSubcommand("push", new GitPush())
> .addSubcommand("rebase", new GitRebase())
> .addSubcommand("tag", new GitTag());
>
> It is strongly recommended that subcommands have a @Command
> annotation with name and description attributes.
> ~
> > It also has other nice features that you might be interested in, like usage
> > help with ANSI colors, ... and much
> > more.
>
> Does it come with ANSI colors? Will it also dance the macarena for me?
>
> I can't even get what is the point of going through such hoops, when,
> to me, all you need is for a HashMap<String><String[]> to be returned
> to you. Users shouldn’t be forced to enter command line arguments in a
> strict way and order and they should be able to chose the character
> encoding of the data they will be feeding into a program (you can’t
> expect for every text on a corpus to be encoded as ASCII or UTF-8).To
> me this is all there should be to such an utility.
>
> Command line arguments are interpreted as strings in the local
> character encoding anyway, right? You would take it from there,
> interpreting those sequences of characters with whichever semantics
> your code needs to define:
>
> HashMap<String, String[]> HMSSAr ...
>
> String[] aIVal00 = HMSSAr.get("--int-val00");
> int iVal00 = (new Integer(aVal00[0])).intValue();
>
> String[] aLVal02 = HMSSAr.get("--long-val02");
> long lVal02 = (new Integer(aLVal02[0])).longValue();
>
> String[] aSAr = HMSSAr.get("--strings-ar00");
> KCommandObjects KCObjs = new KcommandObjects[aSAr.length];
> HashMap<String, Integer> HMSI = new HashMap<String, Integer>();
> for(int k = 0; (k < aSAr.length) ;++k){
> HMSI.put(aSAr[k], k);
> KCObjs[k] = Class.forname(aSAr[k]).newInstance();
> }// k [0, aSAr.length)
>
> . . .
>
> I am half way into finishing such a thing, which I thought someone
> must had done already. Then I will try to integrate with commons-cli
> or put it out there.
>
> I would like to still understand why is it that there exist so many
> libraries which complicate such matters and why is it that java itself
> doesn't offer a basic option like the one I have described.
Unfortunately CLI parsing *is* quite complicated.
For example, how do you handle missing parameters?
Assume -a, -b, -c all take one parameter.
How do you parse:
$ sample -a one -b -c two
Is that:
-a => one
-b => -c
rest: two
Or does that cause a parsing error, because -b has no parameter?
What if -b has an optional parameter?
Does that mean -c is set to two?
As I recall, there are various different syntaxes for CLI lines, and
these handle the above example in different ways.
I'm not even sure there are any standards for these syntaxes.
This makes it all rather messy and complicated.
> lbrtchx
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [commons-cli] handling properties files as default . . .
Posted by Albretch Mueller <lb...@gmail.com>.
On 2/10/19, sebb <se...@gmail.com> wrote:
>
> Unfortunately CLI parsing *is* quite complicated.
>
> For example, how do you handle missing parameters?
> Assume -a, -b, -c all take one parameter.
> How do you parse:
>
> $ sample -a one -b -c two
>
> Is that:
> -a => one
> -b => -c
> rest: two
>
> Or does that cause a parsing error, because -b has no parameter?
>
> What if -b has an optional parameter?
> Does that mean -c is set to two?
IMO, if a command line parser finds a line sequence like:
$ sample -a one -b -c two
it should print a warning to System.err and return;
-a:one
-b:null
-c:two
On 2/11/19, Remko Popma <re...@gmail.com> wrote:
> Picocli's value proposition is that it eliminates boilerplate code from the
> application.
But how, by introducing Picocli's own boilerplate code? Did you look
yourself at the sample Picocli code you posted?
From the little corner from which I see reality:
1) All you need is one line of code in your main start up method
(literally, or if you want to nitpick 3):
HashMap<String, String> HM2SKdCtxt = null;
try{ HM2SKdCtxt = (new
JRIContext00()).getJRIContext(System.currentTimeMillis(), aArgs); }
catch(IOException IOX){ IOX.printStackTrace(System.err); }
2) JRIContext (less than 900 lines of code):
2.1) looks into a global file at the well-known, accessible location:
new File((new File(System.getProperty("user.home"))),
".jricontext.default.properties");
that global property files is read in as a plain java properties file
encoded in ISO 8859-1
2.2) looks into the local directory (System.getProperty("user.dir"))
for all files patterned as:
<java_code_name>_jricontext<_encoding>.properties
2.2.1) sort them by last modified
2.2.2) gives user (2?) seconds (to be implemented using a GUI) to
choose the file to be read with the encoding she means
That local <java_code_name>_jricontext<_encoding>.properties is then
read in using an InputStreamReader with the encoding specified right
in the name.
2.3) all global and local settings are "put" in a hashmap, local
settings take precedence over global ones
2.4) JRIContext then parses the command line as its third and last stage
2.5) all command line parameters, global and local settings are "put"
in a hashmap. command line parameters take precedence over global and
local settings (this is handy when you need to do a quick test)
2.6) There are three baseline parameters which for sanity and
security reasons can't be set as part of the java running instance
either in the properties files or command prompt. They are just
included in JRIContext output for the user to avail herself of such
values if she so decides:
2.6.1) current running's class name which key is: "--jri-klass-name"
2.6.2) start up time in milliseconds (used for log files
redirection): "--jri-startup-time-ms"
2.6.3) the global and local properties file (which are hardcoded):
"--jri-local-props-fl"
2.7) using command objects, JRIContext checks the sanity of all input
data before setting the values
2.8) you can in turn script the properties with any value internally
defined either as System.getProperties() or System.getEnv(). Say if
you are testing some code for which you would like System.out and
System.err to indicated in the suffix the "java.runtime.version" and
"os.version" as returned by System.getProperties(), and
"XDG_CURRENT_DESKTOP" and "XDG_SEAT" by System.getEnv(), you would
just indicated in your properties file:
--jri-log-files-suffix:
("java.runtime.version")_("os.version")_("XDG_CURRENT_DESKTOP")_("XDG_SEAT")
~
Check out JRIContext:
https://sourceforge.net/projects/jricontext/files/JRIX/
I just posted all files there as a proof of concept, I coded the
whole things pretty much in one go. I haven't had the time to take a
second look at it to refine, clean up that code, create javadocs ...
I dropped my initial requirement/ideations to use as metasyntax the
extended Backus Naur form (ISO/IEC
14977) and not a HashMap<String><String[]>, but just a
HashMap<String><String> is returned by jricontext (users should take
care of parsing a, say, pipe delimited String into an array String[]).
Users are not forced to enter command line arguments in a strict way
and order and they are able to chose the character encoding of the
data they will be feeding into a program.
I don't know if apache commons accepts "alternate realities", but I
would clean all that code up, make it play better with apache commons
and maintain it.
I find a bit annoying that java hasn't offered such an utility:
java.util.jricontext?
lbrtchx
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [commons-cli] handling properties files as default . . .
Posted by Remko Popma <re...@gmail.com>.
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.230000, MINUTES.
You selected 1.230000, MINUTES.
You selected 1.230000, 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=<d>] [-u=<unit>] [-x=<x>]
Demonstrate parsing & type conversion
-d=<d>
-h, --help Show this help message and exit.
-u, --timeUnit=<unit>
-V, --version Print version information and exit.
-x=<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 <lb...@gmail.com> wrote:
> On 2/10/19, P. Ottlinger <po...@apache.org> 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 <re...@gmail.com> 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())
> .addSubcommand("status", new GitStatus())
> .addSubcommand("commit", new GitCommit())
> .addSubcommand("add", new GitAdd())
> .addSubcommand("branch", new GitBranch())
> .addSubcommand("checkout", new GitCheckout())
> .addSubcommand("clone", new GitClone())
> .addSubcommand("diff", new GitDiff())
> .addSubcommand("merge", new GitMerge())
> .addSubcommand("push", new GitPush())
> .addSubcommand("rebase", new GitRebase())
> .addSubcommand("tag", new GitTag());
>
> It is strongly recommended that subcommands have a @Command
> annotation with name and description attributes.
> ~
> > It also has other nice features that you might be interested in, like
> usage
> > help with ANSI colors, ... and much
> > more.
>
> Does it come with ANSI colors? Will it also dance the macarena for me?
>
> I can't even get what is the point of going through such hoops, when,
> to me, all you need is for a HashMap<String><String[]> to be returned
> to you. Users shouldn’t be forced to enter command line arguments in a
> strict way and order and they should be able to chose the character
> encoding of the data they will be feeding into a program (you can’t
> expect for every text on a corpus to be encoded as ASCII or UTF-8).To
> me this is all there should be to such an utility.
>
> Command line arguments are interpreted as strings in the local
> character encoding anyway, right? You would take it from there,
> interpreting those sequences of characters with whichever semantics
> your code needs to define:
>
> HashMap<String, String[]> HMSSAr ...
>
> String[] aIVal00 = HMSSAr.get("--int-val00");
> int iVal00 = (new Integer(aVal00[0])).intValue();
>
> String[] aLVal02 = HMSSAr.get("--long-val02");
> long lVal02 = (new Integer(aLVal02[0])).longValue();
>
> String[] aSAr = HMSSAr.get("--strings-ar00");
> KCommandObjects KCObjs = new KcommandObjects[aSAr.length];
> HashMap<String, Integer> HMSI = new HashMap<String, Integer>();
> for(int k = 0; (k < aSAr.length) ;++k){
> HMSI.put(aSAr[k], k);
> KCObjs[k] = Class.forname(aSAr[k]).newInstance();
> }// k [0, aSAr.length)
>
> . . .
>
> I am half way into finishing such a thing, which I thought someone
> must had done already. Then I will try to integrate with commons-cli
> or put it out there.
>
> I would like to still understand why is it that there exist so many
> libraries which complicate such matters and why is it that java itself
> doesn't offer a basic option like the one I have described.
>
> lbrtchx
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: [commons-cli] handling properties files as default . . .
Posted by Albretch Mueller <lb...@gmail.com>.
On 2/10/19, P. Ottlinger <po...@apache.org> 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 <re...@gmail.com> 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())
.addSubcommand("status", new GitStatus())
.addSubcommand("commit", new GitCommit())
.addSubcommand("add", new GitAdd())
.addSubcommand("branch", new GitBranch())
.addSubcommand("checkout", new GitCheckout())
.addSubcommand("clone", new GitClone())
.addSubcommand("diff", new GitDiff())
.addSubcommand("merge", new GitMerge())
.addSubcommand("push", new GitPush())
.addSubcommand("rebase", new GitRebase())
.addSubcommand("tag", new GitTag());
It is strongly recommended that subcommands have a @Command
annotation with name and description attributes.
~
> It also has other nice features that you might be interested in, like usage
> help with ANSI colors, ... and much
> more.
Does it come with ANSI colors? Will it also dance the macarena for me?
I can't even get what is the point of going through such hoops, when,
to me, all you need is for a HashMap<String><String[]> to be returned
to you. Users shouldn’t be forced to enter command line arguments in a
strict way and order and they should be able to chose the character
encoding of the data they will be feeding into a program (you can’t
expect for every text on a corpus to be encoded as ASCII or UTF-8).To
me this is all there should be to such an utility.
Command line arguments are interpreted as strings in the local
character encoding anyway, right? You would take it from there,
interpreting those sequences of characters with whichever semantics
your code needs to define:
HashMap<String, String[]> HMSSAr ...
String[] aIVal00 = HMSSAr.get("--int-val00");
int iVal00 = (new Integer(aVal00[0])).intValue();
String[] aLVal02 = HMSSAr.get("--long-val02");
long lVal02 = (new Integer(aLVal02[0])).longValue();
String[] aSAr = HMSSAr.get("--strings-ar00");
KCommandObjects KCObjs = new KcommandObjects[aSAr.length];
HashMap<String, Integer> HMSI = new HashMap<String, Integer>();
for(int k = 0; (k < aSAr.length) ;++k){
HMSI.put(aSAr[k], k);
KCObjs[k] = Class.forname(aSAr[k]).newInstance();
}// k [0, aSAr.length)
. . .
I am half way into finishing such a thing, which I thought someone
must had done already. Then I will try to integrate with commons-cli
or put it out there.
I would like to still understand why is it that there exist so many
libraries which complicate such matters and why is it that java itself
doesn't offer a basic option like the one I have described.
lbrtchx
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [commons-cli] handling properties files as default . . .
Posted by "P. Ottlinger" <po...@apache.org>.
Another way to help out (from the ASF universe) would be:
https://tamaya.apache.org/
Have fun
Phil
Am 10.02.19 um 12:50 schrieb Gary Gregory:
> It sounds like Commons Configuration would help as well.
>
> Gary
>
> On Sat, Feb 9, 2019, 20:34 Remko Popma <remko.popma@gmail.com wrote:
>
>> 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 <lb...@gmail.com> 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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: user-help@commons.apache.org
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [commons-cli] handling properties files as default . . .
Posted by Gary Gregory <ga...@gmail.com>.
It sounds like Commons Configuration would help as well.
Gary
On Sat, Feb 9, 2019, 20:34 Remko Popma <remko.popma@gmail.com wrote:
> 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 <lb...@gmail.com> 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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@commons.apache.org
> >
>
Re: [commons-cli] handling properties files as default . . .
Posted by Remko Popma <re...@gmail.com>.
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 <lb...@gmail.com> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
Re: [commons-cli] handling properties files as default . . .
Posted by Albretch Mueller <lb...@gmail.com>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org