[cli] Validate CLI script
Hi, Is it possible to build a parser to create and verify CLI script? For example, config set set unset config set end end Thanks, Pratik
[cli] Apache CLI website issue
To whom it may concern, The link for the CLI Javadocs on the website (http://commons.apache.org/proper/commons-cli//api-release/index.html) is broken. Please fix. Thanks, Miraj
[cli]
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?
[cli]
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] Apache CLI website issue
On 02/27/2013 01:31 AM, Miraj Shah wrote: > To whom it may concern, > > The link for the CLI Javadocs on the website > (http://commons.apache.org/proper/commons-cli//api-release/index.html) is > broken. Please fix. We are currently working on these issues, to access it you can use this link instead: http://commons.apache.org/proper/commons-cli/javadocs/api-release/index.html Thomas - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
CLI 2
Hello, I am currently implementing a codegenerator and decided to use CLI for command line parsing. As CLI 1.x leaves me with a lot of validation work to be done, I decided to give CLI2 a try. It works a lot better for me, but I still have some problems. Perhaps there are some ideas to solve them. The first argument of the command-line should be the target-language to generate. As far as I understund, I have two possibilies for this: CommandOption and ArgumentOption+EnumValidator. The CommandOption has the problem, that I can't define that they are mutually exclusive. With the ArgumentOption+EnumValidator the output of the HelpFormatter misses the possible values. When I am using a FileValidator for a argument, e.g. to specify the ouput-directory and enforce it is existing, I get an "Unexpected value" error if the directory does not exist. I would expect that the argument is recognized and a suitable error-message is printed. Greets Wolfgang - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[CLI] Status?
What is going on with commons-cli? I haven't seen any announcements or even much chatter at all about this package. Is the -2.0 stuff going to be rolled back or no? If not, please put out -SNAPSHOT releases to the Maven repos for testing. Thanks! -jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli]
Hi tobias, You may want to take a look at picocli <https://picocli.info/>. Picocli is a modern library with support for mutually exclusive options <https://picocli.info/#_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: [cli]
Just for completeness, there is also JCommander which is quite good IMO (I'm not a maintainer; -) Gary On Thu, Mar 18, 2021, 05:45 Remko Popma wrote: > Hi tobias, > > You may want to take a look at picocli <https://picocli.info/>. > Picocli is a modern library with support for mutually exclusive options > <https://picocli.info/#_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: [cli]
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]
On 13/01/2022 00:13, Remko Popma wrote:
With Commons Cli you will have to write a custom HelpFormatter to provide
end users with more detail about the positional parameters.
Strange. It's almost as if the software was left unfinished, and yet it
is still maintained. The actual program parameters are treated almost as
if they are of slight importance ;)
You may be interested inhttps://picocli.info/ which provides this
functionality
At first sight, that looks highly professional and well documented.
Congratulations. I shall certainly be looking at it for the next time.
I've gone too far with the current program now, but fwiw, the nasty
kludge I used (which involved replacing a private method) is as follows:
new HelpFormatter() {
private Appendable renderWrappedTextBlock(final StringBuffer sb,
final int width, final int nextLineTabStop,
final String text) {
try {
final BufferedReader in = new BufferedReader(new
StringReader(text));
String line;
boolean firstLine = true;
while ((line = in.readLine()) != null) {
if (!firstLine) {
sb.append(getNewLine());
} else {
firstLine = false;
}
renderWrappedText(sb, width, nextLineTabStop, line);
}
} catch (final IOException e) { // NOPMD
// cannot happen
}
return sb;
}
@Override
public void printWrapped(final java.io.PrintWriter pw, final int
width, final int nextLineTabStop,
final String text) {
final StringBuffer sb = new StringBuffer(text.length());
renderWrappedTextBlock(sb, width, nextLineTabStop, text);
sb.append(" ").append("");
pw.println(sb.toString());
}
}.printHelp("FileRenamer", "", options, null, true);
[cli] Commons CLI silently removes numbers from arguments
Hi, It seems that Commons CLI will silently remove numbers from long options like "--channel2" so that it becomes "--channel". But it still allows defining options like "channel2" without exceptions. This is unintuitive behaviour, as an argument meant for "channel2" will be received for "channel". If I supply arguments for both "channel" and "channel2", the one for "channel2" is simply silently ignored. Here is a project to test: https://github.com/ysangkok/cli-problem Regards, Janus - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[cli] - how to use CLI for Java like properties
Hi,
I want to use CLI (version 1.2) to parse Java like properties,
ie. java -DnodeName=MyServer -DnodeIp=10.1.2.2 -DnodePort=1003
here is my test code:
Option helpOp = new Option("h", "command line help");
Option nodeNameOp = OptionBuilder.withArgName( "nodeName=value" )
.hasArgs(2)
.withValueSeparator()
.withDescription( "the server name" )
.create( "D" );
Option nodeIpOp = OptionBuilder.withArgName( "nodeIp=value" )
.hasArgs(2)
.withValueSeparator()
.withDescription( "server ip" )
.create( "D" );
Option nodePortOp = OptionBuilder.withArgName( "nodePort=value" )
.hasArgs(2)
.withValueSeparator()
.withDescription( "server port" )
.create( "D" );
Options cmdOptions = new Options();
cmdOptions.addOption(helpOp);
cmdOptions.addOption(nodeNameOp);
cmdOptions.addOption(nodeIpOp);
cmdOptions.addOption(nodePortOp);
HelpFormatter helpFormatter = new HelpFormatter();
helpFormatter.printHelp("command line help", cmdOptions);
and here is the output:
usage: command line help
-Dserver port
-h command line help
Why the help displays only "NodePort"？
Could anybody give me an example code to use CLI for Java properties?
Thanks
Joey Lv
12/24/2011
Re: [cli] Commons CLI silently removes numbers from arguments
Hello Janus, thank you for your report and the example repository. Feel free to create a new JIRA ticket for the CLI component [1]. If you like, you can even provide a fix either as a svn diff file for the CLI svn repository [2] or as pull request for our github mirror [3]. Don't forget to add some unit tests verifying your changes. best regards, Benedikt [1] https://issues.apache.org/jira/browse/CLI [2] https://svn.apache.org/repos/asf/commons/proper/cli/trunk [3] https://github.com/apache/commons-cli 2015-10-15 21:41 GMT+02:00 Janus Troelsen : > Hi, > > It seems that Commons CLI will silently remove numbers from long > options like "--channel2" so that it becomes "--channel". But it still > allows defining options like "channel2" without exceptions. This is > unintuitive behaviour, as an argument meant for "channel2" will be > received for "channel". If I supply arguments for both "channel" and > "channel2", the one for "channel2" is simply silently ignored. > > Here is a project to test: > > https://github.com/ysangkok/cli-problem > > Regards, > Janus > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Commons CLI issue
I think I must be misunderstanding something about the hasArgs. The
program that follows produces:
[javac] Compiling 1 source file
to /home/users/russel/Progs/OddsByLanguage/Java/CommonsCLI_Test
[java] -D blah=Hello
[java] -D burble=thing
[java] -D flob=adob
[java] -D print
[java]
[java] usage: Usage statement
[java] -DDefinition of something.
in both 1.0 and 1.1. I had assumed that print would not be treated a a
-D option. Alternatively this is a bug in which case I will create a
JIRA issue -- unlikely I suspect though, much more likely to be
something stupid on my part.
Thanks.
import java.io.PrintWriter ;
import org.apache.commons.cli.CommandLine ;
import org.apache.commons.cli.OptionBuilder ;
import org.apache.commons.cli.GnuParser ;
import org.apache.commons.cli.HelpFormatter ;
import org.apache.commons.cli.Option ;
import org.apache.commons.cli.Options ;
import org.apache.commons.cli.ParseException ;
import org.apache.commons.cli.PosixParser ;
public class Trial {
private void execute ( final String[] commandLine ) throws ParseException {
final Options options = new Options ( ) ;
options.addOption ( OptionBuilder.hasArgs ( ).withDescription ( "Definition
of something." ).create ( 'D' ) ) ;
final CommandLine line = ( new GnuParser ( ) ).parse ( options ,
commandLine ) ;
String[] results = line.getOptionValues ( 'D' ) ;
if ( results != null ) { for ( String s : results ) { System.out.println (
"-D " + s ) ; } }
String[] theRest = line.getArgs ( ) ;
for ( String s : theRest ) { System.out.print ( s + " " ) ; }
System.out.println ( ) ;
final HelpFormatter formatter = new HelpFormatter ( ) ;
final PrintWriter writer = new PrintWriter ( System.out ) ;
//formatter.printHelp ( writer , formatter.defaultWidth , "Usage statement"
, "" , options , formatter.defaultLeftPad , formatter.defaultDescPad , "" ) ;
formatter.printHelp ( writer , formatter.getWidth ( ) , "Usage statement" ,
"" , options , formatter.getLeftPadding ( ) , formatter.getDescPadding ( ) , ""
) ;
writer.flush ( ) ;
}
public static void main ( final String[] args ) throws ParseException {
final Trial trial = new Trial ( ) ;
trial.execute ( new String[] { "-Dblah=Hello" , "-Dburble=thing" ,
"-Dflob=adob" , "print" } ) ;
}
}
--
Russel.
Dr Russel Winder
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK t: +44 20 7585 2200
signature.asc
Description: This is a digitally signed message part
Re: CLI 2
Hi Wolfgang, there are a lot of code generators out there. if you want to save time, try for example velocity (http://velocity.apache.org/). It does a fairly good job. It is template based and you can even code your needs in the templates (for example iterate over classes in your uml model). Sorry that this is not an answer to your question... Greetings, Lian On 8/4/07, Wolfgang Roessler <[EMAIL PROTECTED]> wrote: > > Hello, > > I am currently implementing a codegenerator and decided to use CLI for > command line parsing. As CLI 1.x leaves me with a lot of validation work > to be done, I decided to give CLI2 a try. It works a lot better for me, > but I still have some problems. Perhaps there are some ideas to solve > them. > > The first argument of the command-line should be the target-language to > generate. As far as I understund, I have two possibilies for this: > CommandOption and ArgumentOption+EnumValidator. The CommandOption has > the problem, that I can't define that they are mutually exclusive. With > the ArgumentOption+EnumValidator the output of the HelpFormatter misses > the possible values. > > When I am using a FileValidator for a argument, e.g. to specify the > ouput-directory and enforce it is existing, I get an "Unexpected value" > error if the directory does not exist. I would expect that the argument > is recognized and a suitable error-message is printed. > > Greets > Wolfgang > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: CLI 2
Hi Lian, I am using openArchitectureware as the codegenerator framework and the generated target-languages may be rather exotic (e.g. Structured Text as defined in IEC 61131-3). But thanks for the hint, I think I should take a look at velocity and compare it with OAW. Greets Wolfgang Hi Wolfgang, there are a lot of code generators out there. if you want to save time, try for example velocity (http://velocity.apache.org/). It does a fairly good job. It is template based and you can even code your needs in the templates (for example iterate over classes in your uml model). Sorry that this is not an answer to your question... Greetings, Lian On 8/4/07, Wolfgang Roessler <[EMAIL PROTECTED]> wrote: Hello, I am currently implementing a codegenerator and decided to use CLI for command line parsing. As CLI 1.x leaves me with a lot of validation work to be done, I decided to give CLI2 a try. It works a lot better for me, but I still have some problems. Perhaps there are some ideas to solve them. The first argument of the command-line should be the target-language to generate. As far as I understund, I have two possibilies for this: CommandOption and ArgumentOption+EnumValidator. The CommandOption has the problem, that I can't define that they are mutually exclusive. With the ArgumentOption+EnumValidator the output of the HelpFormatter misses the possible values. When I am using a FileValidator for a argument, e.g. to specify the ouput-directory and enforce it is existing, I get an "Unexpected value" error if the directory does not exist. I would expect that the argument is recognized and a suitable error-message is printed. Greets Wolfgang - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CLI 2
Hi Wolfgang, oh sorry, my mistake. Your question sounded as if you would build your own code generator from scratch. OAW does a lot more then velocity. It already has built-in support for different models. And this is very interesting: "The Xtext Framework allows you to define a textual modelling language using a simple BNF-like notation. The Xtext generator creates a corresponding parser, an EMF meta-model and an Eclipse text editor with syntax-highlighting, constraint checking, code completion, an outline view, etc." So in the end i think your choice is good :) Greetings, Lian On 8/5/07, Wolfgang Roessler <[EMAIL PROTECTED]> wrote: > > Hi Lian, > > I am using openArchitectureware as the codegenerator framework and the > generated target-languages may be rather exotic (e.g. Structured Text as > defined in IEC 61131-3). > But thanks for the hint, I think I should take a look at velocity and > compare it with OAW. > > Greets > Wolfgang > > Hi Wolfgang, > > there are a lot of code generators out there. if you want to save time, > try > > for example > > velocity (http://velocity.apache.org/). It does a fairly good job. It is > > template based > > and you can even code your needs in the templates (for example iterate > over > > classes in your uml model). > > Sorry that this is not an answer to your question... > > Greetings, > > Lian > > > > On 8/4/07, Wolfgang Roessler <[EMAIL PROTECTED]> wrote: > > > >> Hello, > >> > >> I am currently implementing a codegenerator and decided to use CLI for > >> command line parsing. As CLI 1.x leaves me with a lot of validation > work > >> to be done, I decided to give CLI2 a try. It works a lot better for me, > >> but I still have some problems. Perhaps there are some ideas to solve > >> them. > >> > >> The first argument of the command-line should be the target-language to > >> generate. As far as I understund, I have two possibilies for this: > >> CommandOption and ArgumentOption+EnumValidator. The CommandOption has > >> the problem, that I can't define that they are mutually exclusive. With > >> the ArgumentOption+EnumValidator the output of the HelpFormatter misses > >> the possible values. > >> > >> When I am using a FileValidator for a argument, e.g. to specify the > >> ouput-directory and enforce it is existing, I get an "Unexpected value" > >> error if the directory does not exist. I would expect that the argument > >> is recognized and a suitable error-message is printed. > >> > >> Greets > >> Wolfgang > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[CLI] HelpFormatter Question
I have an application that consists of a series of plugins. There are a couple of options that are global (such as "output directory", or "input file"). In addition, each plugin has it's own OptionGroup. I would like to be able print the help for the application in such a way that it's obvious to the users which options go with which plugin, something like this: jartool -i --inputThe input file or directory -o --output The output file or directory -c --cp Include JARs in classpath LicenseExtractorPluginExtracts license files from JAR files -x --licenseExtractor -r --rules [Optional] Use external rules file to locate license FindClassPlugin Finds a class within the JAR file -f --find The regular expression for the class you want to find. Is there a way of doing this with the HelpFormatter? If not, are there any plans on making the HelpFormatter pluggable in CLI2? I could foresee the need to use Velocity or other mechanisms to format the help. Regards, Mark Fortner
Common CLi Usage
Hi
I new to using the apache commons cli I am struggling to get this
correct and would really appreciate any help.
I need to add an option to my command line (-p) with a variable number
of options like the following..
Note there are other options -a, -f, -d but I am not interested in them
for now
e.g
myApp -p [ | | ] -a XXX -d xxx -f XXX
where time is of the format '-MM-DD HH:MM:SS'
Note
1. There is a space between the "-MM-DD" and the "HH:MM:SS"(does
this mean the CLI Parser will see 2 parameters )
2. The and parameters are optional.
3. The parameter is mandatory when using the -p option
I am using the Commons Cli API..
I am trying to define the option as follows but this obviously isnt
correct
final Option persistDataOption =
OptionBuilder.withArgName("persist").hasOptionalArgs(3)
hasArg().withDescription("Persist Data with Scheduling")
.create(CLIOption.PERSIST_DATA.getOptionString());
where
CLIOption.PERSIST_DATA.getOptionString()) will return the "-p" option
Can someone please show me how to define this command line option
correctly please
Thanks in advance
John
> ericssonl
> John O'Sullivan
> Ericsson Software Campus
> Athlone.
> Co. Westmeath
> Ireland
> *ECN 21389
> *External +353 90 6431389
> [EMAIL PROTECTED]
>
>
Re: [CLI] Status?
On Wed, 2008-12-03 at 12:32 -0500, [EMAIL PROTECTED] wrote: > What is going on with commons-cli? I haven't seen any announcements or > even much chatter at all about this package. Is the -2.0 stuff going > to be rolled back or no? If not, please put out -SNAPSHOT releases to > the Maven repos for testing. Thanks! > > -jesse My take on this is that 1.2 is ready to go out as a release candidate and thence to formal release. Certainly I am using 1.2-SNAPSHOT (compiled from my Git repository cloned from the Subversion repository cli-1.x branch) with Groovy and am having no problems. I am guessing that Emmanuel (who has been shepherding the 1.2 evolution) has not had the time to do whatever Apache bureaucracy is needed in order for the release candidate to be blessed and shipped, and the overall release process roll forward towards the joy of having 1.2 formally available. Overall it seems that Commons CLI has no future since no-one is interested in it enough to take it forward. -- Russel. Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077 signature.asc Description: This is a digitally signed message part
[cli] Downloading snapshots
It's been a year since I last downloaded a snapshot of commons-cli-2.0, which I have been happily using, but I thought I would check back for a newer copy. Unfortunately, my memory is failing, no doubt due to advancing age and I can't remember (or find) where do get a copy. Can someone give me a clue :-/ TIA, roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises rol...@rlenter.com6818 Madeline Court rol...@astrofoto.org Brooklyn, NY 11220 - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
CLI 1.2: HelpFormatter.printHelp()
Hi
I have the following program which initially has one option, and print the
usage using HelpFormatter:
OptionBuilder.withDescription("Test
1").withLongOpt("test1").hasArg().isRequired();
options.addOption(OptionBuilder.create("a"));
HelpFormatter formatter = new HelpFormatter();
formatter.printHelp(100, "Dummy", null, options, null, true);
The HelpFormatter.printHelp() prints the following:
usage: Dummy -a
-a,--test1Test 1
Then, I added the 2nd option (created like the option "a"):
OptionBuilder.withDescription("Test
2").withLongOpt("test2").hasArg().isRequired();
options.addOption(OptionBuilder.create("b"));
and this time the HelpFormatter.printHelp() prints the following:
usage: Dummy -a -b
-a,--test1 Test 1
-b,--test2Test 2
Again, I added the 3rd option (created like the option "a" and "b"):
OptionBuilder.withDescription("Test
3").withLongOpt("test3").hasArg().isRequired();
options.addOption(OptionBuilder.create("d"));
and the HelpFormatter.printHelp() prints the following:
usage: Dummy -a -b -d
-a,--test1 Test 1
-b,--test2Test 2
-d,--test3Test 3
Why doesn't HelpFormatter.printHelp() prints the for the -a option
while all options are created the same way?
It should print the usage like the following, right?
usage: Dummy -a -b -d
-a,--test1Test 1
-b,--test2Test 2
-d,--test3Test 3
--
Hez
CLI - withValueSeparator problem
>From CLI official site
http://commons.apache.org/cli/usage.html
>>>>>>>> expected result >>>>>>>>>>>>
--block-size=SIZE use SIZE-byte blocks
>>>>>>>>>>>> code >>>>>>>>>>>>>>
Options.addOption( OptionBuilder.withLongOpt( "block-size" )
.withDescription( "use SIZE-byte blocks" )
.hasArg()
.withArgName("SIZE")
.create() );
>>>>>>>> real result >>>>>>>>>>>>
--block-size SIZE use SIZE-byte blocks
>>>>>>>> then, I've tried >>>>>>>>>>>>
Options.addOption( OptionBuilder.withLongOpt( "block-size" )
.withDescription( "use SIZE-byte blocks" )
.hasArg()..withValueSeparator('=')
.withArgName("SIZE")
.create() );
>>>>>>>> but I still got this >>>>>>>>>>>>
--block-size SIZE use SIZE-byte blocks
Please help!
TIA
Leo
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
[CLI] Using OptionGroups
Hello all,
First of all I thank you for Commons CLI, such a useful library!
Question:
I have two sets of arguments in my command line java program, I haven't been
able to find documentation on how to handle different OptionGroups, I want to
have the program detect that it got either group1, group2 or help. To make it
interesting, group 1 contains required and not required arguments.
I am using release 1.2 and here's my code so far:
Option in = OptionBuilder.hasArg().withArgName("file")
.withLongOpt("in").withDescription("VCD file to
convert.")
.create("i");
in.setRequired(true);
Option out = OptionBuilder.hasArg().withArgName("file")
.withLongOpt("out").withDescription("Output CSV
file.")
.create("o");
out.setRequired(true);
Option getsignals = new Option(
"g",
"getsignals",
false,
"Gets a list of signals available in a VCD
file. Use in conjunction with the i option only.");
getsignals.setRequired(true);
Option signals = OptionBuilder
.hasArgs()
.withArgName("signalList")
.withLongOpt("signals")
.withDescription(
"Comma separated list of
requested signals to include in the CSV.")
.withValueSeparator(',').withType(new
ArrayList())
.create("s");
signals.setRequired(true);
Option timeUnit = OptionBuilder
.hasArg()
.withLongOpt("timeUnit")
.withDescription(
"Time units to use. Options:
'ms','us' or 'ns'.")
.create("t");
timeUnit.setRequired(false);
Option noDuplicates = new Option("n", "noDuplicates", false,
"Set flag to remove duplicate time entries.");
noDuplicates.setRequired(false);
Option append = new Option("a", "append", false,
"Set flag to append information to existing
CSV.");
append.setRequired(false);
Option getDeltas = new Option("d", "deltas", false,
"Set to calculate delta values between
entries.");
getDeltas.setRequired(false);
Option help = new Option("h", "help", false,
"Prints usage information.");
help.setRequired(true);
// Group for converting:
options = new Options();
OptionGroup groupConvert = new OptionGroup();
groupConvert.addOption(in);
groupConvert.addOption(out);
groupConvert.addOption(signals);
groupConvert.addOption(timeUnit);
groupConvert.addOption(noDuplicates);
groupConvert.addOption(append);
groupConvert.addOption(getDeltas);
groupConvert.addOption(getsignals);
groupConvert.setRequired(true);
// Group for viewing signals
OptionGroup groupViewSignals = new OptionGroup();
groupViewSignals.addOption(in);
groupViewSignals.addOption(getsignals);
groupViewSignals.setRequired(true);
options.addOption(help);
options.addOptionGroup(groupConvert);
options.addOptionGroup(groupViewSignals);
Thanks!
Andrei Viesca
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
[CLI] - withValueSeparator() usage
I'm struggling on how to use the withValueSeparator() option;
Taking the following piece of code ...
Options options = new Options();
Option columns = OptionBuilder
.hasArg()
.withArgName("CSV columns")
.withValueSeparator(',')
.withDescription("Specify the comma separated
list of columns")
.create("columns");
options.addOption(columns);
CommandLineParser parser = new GnuParser();
CommandLine line = parser.parse(options, new String[]{ "-columns",
"a,b,c"});
System.out.println("hasOption:" + line.hasOption("columns"));
System.out.println("column count:" +
line.getOptionValues("columns").length);
I woudl expect it to print out something like:
hasOption:true
column count:3
whereas in fact I'm getting
hasOption:true
column count:1
i.e. despite me specifying ',' as a value separator, getOptionValues() is
returning a array that is one element in size, containing "a,b,c" instead
of three elements, each containing a single letter.
I'm missing something - what it is?
Thanks,
Greg
[cli] Submiting patches
Can anybody tell me how to submit my patches. Thank You, Isuranga Perera
Re: [cli] - how to use CLI for Java like properties
I *think* because you created them all with "D" and so it only kept the
last one. I think tobdo what you want you would call create with
"DnodeName" for example.
Why do you want this at all? Why not just let the JVM parse the properties
from the cmd line?
Bill-
On Dec 24, 2011 12:44 AM, "LvXiaoyi" wrote:
>
>
>
>
> Hi,
> I want to use CLI (version 1.2) to parse Java like properties,
> ie. java -DnodeName=MyServer -DnodeIp=10.1.2.2 -DnodePort=1003
>
> here is my test code:
> Option helpOp = new Option("h", "command line help");
>
> Option nodeNameOp = OptionBuilder.withArgName( "nodeName=value" )
>.hasArgs(2)
>.withValueSeparator()
>.withDescription( "the server name" )
>.create( "D" );
>
> Option nodeIpOp = OptionBuilder.withArgName( "nodeIp=value" )
>.hasArgs(2)
>.withValueSeparator()
>.withDescription( "server ip" )
>.create( "D" );
>
> Option nodePortOp = OptionBuilder.withArgName( "nodePort=value" )
>.hasArgs(2)
>.withValueSeparator()
>.withDescription( "server port" )
>.create( "D" );
>
> Options cmdOptions = new Options();
> cmdOptions.addOption(helpOp);
> cmdOptions.addOption(nodeNameOp);
> cmdOptions.addOption(nodeIpOp);
> cmdOptions.addOption(nodePortOp);
>
>
> HelpFormatter helpFormatter = new HelpFormatter();
> helpFormatter.printHelp("command line help", cmdOptions);
>
> and here is the output:
> usage: command line help
> -Dserver port
> -hcommand line help
>
> Why the help displays only "NodePort"？
>
> Could anybody give me an example code to use CLI for Java properties?
>
> Thanks
>
> Joey Lv
>
> 12/24/2011
>
>
>
>
Re: [cli] - how to use CLI for Java like properties
NI-hao,
I think you misinterpreted the argument creation, just declare the
dynamic option once:
Option property = OptionBuilder.withArgName( "property=value" )
.hasArgs(2)
.withValueSeparator()
.withDescription( "use value for given
property" )
.create( "D" );
The once obtained the CommandLine instance, invoke the
getOptionProperties()[1] method:
Properties dynaProperties = commandLine.getOptionProperties( "D" );
HTH!
-Simo
[1]
http://commons.apache.org/cli/api-release/org/apache/commons/cli/CommandLine.html#getOptionProperties(java.lang.String)
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
2011/12/24 LvXiaoyi :
>
>
>
>
> Hi,
> I want to use CLI (version 1.2) to parse Java like properties,
> ie. java -DnodeName=MyServer -DnodeIp=10.1.2.2 -DnodePort=1003
>
> here is my test code:
> Option helpOp = new Option("h", "command line help");
>
> Option nodeNameOp = OptionBuilder.withArgName( "nodeName=value" )
> .hasArgs(2)
> .withValueSeparator()
> .withDescription( "the server name" )
> .create( "D" );
>
> Option nodeIpOp = OptionBuilder.withArgName( "nodeIp=value" )
> .hasArgs(2)
> .withValueSeparator()
> .withDescription( "server ip" )
> .create( "D" );
>
> Option nodePortOp = OptionBuilder.withArgName( "nodePort=value" )
> .hasArgs(2)
> .withValueSeparator()
> .withDescription( "server port" )
> .create( "D" );
>
> Options cmdOptions = new Options();
> cmdOptions.addOption(helpOp);
> cmdOptions.addOption(nodeNameOp);
> cmdOptions.addOption(nodeIpOp);
> cmdOptions.addOption(nodePortOp);
>
>
> HelpFormatter helpFormatter = new HelpFormatter();
> helpFormatter.printHelp("command line help", cmdOptions);
>
> and here is the output:
> usage: command line help
> -D server port
> -h command line help
>
> Why the help displays only "NodePort"？
>
> Could anybody give me an example code to use CLI for Java properties?
>
> Thanks
>
> Joey Lv
>
> 12/24/2011
>
>
>
>
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
[CLI] parameter between quotes
Hi,
i want to make an option like:
command -i "bla bla bla bla"
how may i do this?
This is my code:
-
commandLineOptions.addOption(
OptionBuilder.withArgName("statement")
.hasArg().withDescription("interprets quoted string statement")
.withLongOpt("interpret")
.withValueSeparator('=')
.create("i")
);
--
Öğr. Gör. Fırat KÜÇÜK
ADAMYO Distance Learning
SAKARYA University / TURKEY
Re: Commons CLI issue
I'd suggest to ask that on the dev list ...a few cli issues have been
brought up there lately
cheers
--
Torsten
On 31.07.2007, at 18:28, Russel Winder wrote:
I think I must be misunderstanding something about the hasArgs. The
program that follows produces:
[javac] Compiling 1 source file
to /home/users/russel/Progs/OddsByLanguage/Java/CommonsCLI_Test
[java] -D blah=Hello
[java] -D burble=thing
[java] -D flob=adob
[java] -D print
[java]
[java] usage: Usage statement
[java] -DDefinition of something.
in both 1.0 and 1.1. I had assumed that print would not be treated
a a
-D option. Alternatively this is a bug in which case I will create a
JIRA issue -- unlikely I suspect though, much more likely to be
something stupid on my part.
Thanks.
import java.io.PrintWriter ;
import org.apache.commons.cli.CommandLine ;
import org.apache.commons.cli.OptionBuilder ;
import org.apache.commons.cli.GnuParser ;
import org.apache.commons.cli.HelpFormatter ;
import org.apache.commons.cli.Option ;
import org.apache.commons.cli.Options ;
import org.apache.commons.cli.ParseException ;
import org.apache.commons.cli.PosixParser ;
public class Trial {
private void execute ( final String[] commandLine ) throws
ParseException {
final Options options = new Options ( ) ;
options.addOption ( OptionBuilder.hasArgs ( ).withDescription
( "Definition of something." ).create ( 'D' ) ) ;
final CommandLine line = ( new GnuParser ( ) ).parse
( options , commandLine ) ;
String[] results = line.getOptionValues ( 'D' ) ;
if ( results != null ) { for ( String s : results )
{ System.out.println ( "-D " + s ) ; } }
String[] theRest = line.getArgs ( ) ;
for ( String s : theRest ) { System.out.print ( s + " " ) ; }
System.out.println ( ) ;
final HelpFormatter formatter = new HelpFormatter ( ) ;
final PrintWriter writer = new PrintWriter ( System.out ) ;
//formatter.printHelp ( writer , formatter.defaultWidth ,
"Usage statement" , "" , options , formatter.defaultLeftPad ,
formatter.defaultDescPad , "" ) ;
formatter.printHelp ( writer , formatter.getWidth ( ) , "Usage
statement" , "" , options , formatter.getLeftPadding ( ) ,
formatter.getDescPadding ( ) , "" ) ;
writer.flush ( ) ;
}
public static void main ( final String[] args ) throws
ParseException {
final Trial trial = new Trial ( ) ;
trial.execute ( new String[] { "-Dblah=Hello" , "-
Dburble=thing" , "-Dflob=adob" , "print" } ) ;
}
}
--
Russel.
Dr Russel Winder
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK t: +44 20 7585 2200
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons CLI issue
On Sat, 2007-08-11 at 20:32 +0200, Torsten Curdt wrote: > I'd suggest to ask that on the dev list ...a few cli issues have been > brought up there lately OK, thanks for letting me know. It is difficult to decide if CLI is a live project or a dead project - despite my recent direct email exchange with Henri. We use it in Groovy, but there is a growing feeling in the team that we should fork the CLI code so we can get the fixes we need in place ready for the next Groovy release. The decision is really whether to fork the unreleased 2.x or the the released 1.x branch. -- Russel. Dr Russel Winder 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK t: +44 20 7585 2200 signature.asc Description: This is a digitally signed message part
Re: Commons CLI issue
On 13.08.2007, at 07:37, Russel Winder wrote: On Sat, 2007-08-11 at 20:32 +0200, Torsten Curdt wrote: I'd suggest to ask that on the dev list ...a few cli issues have been brought up there lately OK, thanks for letting me know. It is difficult to decide if CLI is a live project or a dead project - despite my recent direct email exchange with Henri. We use it in Groovy, but there is a growing feeling in the team that we should fork the CLI code so we can get the fixes we need in place ready for the next Groovy release. The decision is really whether to fork the unreleased 2.x or the the released 1.x branch. Please - please don't fork. I am sure we will get your patches in. We just need someone to push for it. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons CLI issue
On Mon, 2007-08-13 at 09:19 +0200, Torsten Curdt wrote: > Please - please don't fork. I am sure we will get your patches in. We > just need someone to push for it. That's what I like to hear :-) The single biggest decision that needs to be made is whether the current 2.x branch is the future or whether it should be deleted and the 1.x branch continue as the released CLI. If 2.x is the future then there needs to be a release and a version put into the Maven repository. I believe Henri is more interested in the 1.x branch, which is why the 2.x branch has not been progressed, but I am speaking from a position of fairly deep ignorance. Clearly 1.1 has many bug fixes over 1.0 and so would be preferred. However the combination of the change of semantics with hasArgs and incorrect processing of parameters associated with the new semantics (cf. CLI-137) means that there appears to be a blocking problem in processing options such as -D where there can be any number of them on a command line -- there appears to be no problem with options that do not have Option.UNLIMITED_VALUES set. As I say we can use the 1.0 semantics and hack round things, but we cannot use 1.1 because of the incorrect processing :-( The other thing I need is the -- option that terminates option processing. This is in 2.x but not in 1.x I believe. If Commons CLI is to be reenergized (over and above what Henri did to get 1.1 out) then this is a good thing. -- Russel. Dr Russel Winder 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK t: +44 20 7585 2200 signature.asc Description: This is a digitally signed message part
Re: Commons CLI issue
Hi, I came across CLI some time ago, when I was looking for a "framework" to help me process the command-line easily. I tried CLI1.1 and CLI2 and I have to admit, I am satisfied with neither. While parsing works as far as I have tried, the validation (which I consider more important and costly) is not yet what I expect. While CLI1.1 offers nothing, CLI2 at least has some simple checks. I would need a flexible approach for modelling (complex) dependencies. What I would expect is, that I only have to specify the command-line (available options, dependencies, special validations ...) and all parsing and validation is done for me. I don't only want to complain about the situation, but I want to offer my help. If there is a clear direction where to go, I am willing to invest some time to help with a new release. The idee of CLI is great, but for a really useful solution in my opinion a lot has to be improved. Greets Wolfgang - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons CLI issue
Please - please don't fork. I am sure we will get your patches in. We just need someone to push for it. That's what I like to hear :-) :) If Commons CLI is to be reenergized (over and above what Henri did to get 1.1 out) then this is a good thing. Well, as said: come and join us on the dev list. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons CLI issue
I don't only want to complain about the situation, but I want to offer my help. If there is a clear direction where to go, I am willing to invest some time to help with a new release. The idee of CLI is great, but for a really useful solution in my opinion a lot has to be improved. You are more than welcome over on the dev list! cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons CLI issue
On 8/13/07, Russel Winder <[EMAIL PROTECTED]> wrote: > On Mon, 2007-08-13 at 09:19 +0200, Torsten Curdt wrote: > > > Please - please don't fork. I am sure we will get your patches in. We > > just need someone to push for it. +1 > I believe Henri is more interested in the 1.x branch, which is why the 2.x > branch has not been progressed, but I am speaking from a position of > fairly deep ignorance. I'm equally interested :) Getting a 1.1 release out made the most sense with the time available - plus Brian was energetic in that direction. When I tried to use CLI2 I didn't like the API a lot, but I was just dabbling and not trying to get the extra features that it supports (I assume). I seem to recall I found it much more verbose than CLI1 which surprised me. Now my energy for CLI is squarely available for CLI2 if there's interest out there. I can see a CLI 1.2 someday if need be, but hopefully it'll just be a few bugfixes and we can have people use the snapshots for that branch. > Clearly 1.1 has many bug fixes over 1.0 and so would be preferred. > However the combination of the change of semantics with hasArgs and > incorrect processing of parameters associated with the new semantics > (cf. CLI-137) means that there appears to be a blocking problem in > processing options such as -D where there can be any number of them on a > command line -- there appears to be no problem with options that do not > have Option.UNLIMITED_VALUES set. Any idea for how 2.0 works with this? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons CLI issue
On Tue, 2007-08-14 at 15:16 +0100, Henri Yandell wrote: > On 8/13/07, Russel Winder <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-08-13 at 09:19 +0200, Torsten Curdt wrote: > > > > > Please - please don't fork. I am sure we will get your patches in. We > > > just need someone to push for it. > > +1 I'm hearing :-) > > I believe Henri is more interested in the 1.x branch, which is why the 2.x > > branch has not been progressed, but I am speaking from a position of > > fairly deep ignorance. > > I'm equally interested :) Cool. > Getting a 1.1 release out made the most sense with the time available > - plus Brian was energetic in that direction. When I tried to use CLI2 > I didn't like the API a lot, but I was just dabbling and not trying to > get the extra features that it supports (I assume). I seem to recall I > found it much more verbose than CLI1 which surprised me. I think getting 1.1 out was an excellent move and an excellent decision. The 1.x API is well known and makes some sense. I am only now looking at the 2.x API and because it is different, it is odd. I guess I need to write a few programs to see if it works. I definitely do not like having to say '--xml' as parameter when querying the command line, that strikes me a retrograde. I am assuming that the guys who created CLI2 created the new API not for the sake of it, but because there were serious, unrectifiable problems with the 1.x API. I guess the question is whether this really is the right position. > Now my energy for CLI is squarely available for CLI2 if there's > interest out there. Yes there is, unless all the problems that started the 2.x branch can actually be fixed in 1.x. > I can see a CLI 1.2 someday if need be, but hopefully it'll just be a > few bugfixes and we can have people use the snapshots for that branch. I have put one blocker issue in for 1.1, I can start generating a few more if that helps. What I would like to see is 1.x-SNAPSHOT in the Maven 2 snapshot repository so that progress towards 1.2 is clear and I can use it with bug fixes for the Groovy distribution. (We package Commons CLI in the Groovy distribution so I can go with snapshots :-) > > Clearly 1.1 has many bug fixes over 1.0 and so would be preferred. > > However the combination of the change of semantics with hasArgs and > > incorrect processing of parameters associated with the new semantics > > (cf. CLI-137) means that there appears to be a blocking problem in > > processing options such as -D where there can be any number of them on a > > command line -- there appears to be no problem with options that do not > > have Option.UNLIMITED_VALUES set. > > Any idea for how 2.0 works with this? Not at the minute, I will have to have a play with 2.x. I am not able to progress properly this in the next couple of weeks, but from mid-September onwards I can. For me moving the whole of Commons CLI from Maven 1 to Maven 2 as the primary build system would be good :-) -- Russel. Dr Russel Winder 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK t: +44 20 7585 2200 signature.asc Description: This is a digitally signed message part
[CLI] Usage Patterns Question
I've been using CLI 1 for a while and I noticed that there's been renewed interest in developing CLI2. I was wondering how people are currently using CLI, and whether I'm using it properly? Most of the command line apps that I've developed do more than one thing. In order to make it easier to plugin more functionality I use a basic Command pattern. Each plugin interface looks something like this: Command + isValid(options: Options):boolean + getDescription():String + execute(options:Options):void + getPrimaryOption():Option Each command has a primaryOption which uniquely identifies the command from the command line. For example, if you have a command which scales images, then it might be identified by the --scale option. The main application is responsible for discovering and loading all plugins at runtime (using the SPI mechanism), determining which plugin to execute, and printing out help information. It also invokes the command by first invoking the command's isValid method to validate the input before invoking its execute method. I'm curious if other people are using CLI in a similar manner, or if people create separate CLI applications for each piece of functionality? Regards, -- Mark Fortner blog: http://www.jroller.com/phidias
[CLI] cli2 with subcommands
Greetings, I'm using a CLI2 snapshot and am trying to write a parser for a rather complex command line tool. I have a series of subcommands but I don't see any easy way to print out a Help for it. I can easily print out automatically created Helps for each of the subcommand options, but nothing at the top level. I'd like to just set up my DisplaySetting options and dump the entire command with the formatter also handling any subcommands. mycmd subcmd1 [ ...] subcmd2 [ ...] Also, is there any way to have an optional prefix for the command? I am writing a robot which has heads on IRC as well as AIM. In IRC, I only want it to respond when it sees !mycmd but on AIM I want to respond when it sees mycmd. Right now I'm just testing for !mycmd as the leading string and removing the ! mark. Perhaps this is good enough, I was just curious.. Thanks in advance, -jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release of commons-cli?
Are there any plans to release either 1.2 or 2.0 of commons-cli? I'm particularly interested in the fix for CLI-155. The issue is fixed in the head for 1.x and seems to be a non-issue in 2.x. There was a patch attached to the Jira issue, but I'd like to be able to depend on a non-patched version. When is the next time a release is planned for either of those branches? Thanks, Mike DeLaurentis
Re: Common CLi Usage
On Thu, 2008-05-29 at 12:58 +0200, John O'Sullivan wrote:
> myApp -p [ | | ] -a XXX -d xxx -f XXX
>
> where time is of the format '-MM-DD HH:MM:SS'
> Note
> 1. There is a space between the "-MM-DD" and the "HH:MM:SS"(does
> this mean the CLI Parser will see 2 parameters )
> 2. The and parameters are optional.
> 3. The parameter is mandatory when using the -p option
>
> I am using the Commons Cli API..
> I am trying to define the option as follows but this obviously isnt
> correct
>
> final Option persistDataOption =
> OptionBuilder.withArgName("persist").hasOptionalArgs(3)
> hasArg().withDescription("Persist Data with Scheduling")
> .create(CLIOption.PERSIST_DATA.getOptionString());
> where
> CLIOption.PERSIST_DATA.getOptionString()) will return the "-p" option
>
> Can someone please show me how to define this command line option
> correctly please
I don't have an immediate answer for you I'm afraid. The reason for
replying is to note that this looks almost, but not quite exactly, like
an ISO 8601 date -- the differences are going to be very irritating I
suspect. The though struck me that ISO 8601 date should be a known
construct to any CLI system. Of course, Java's current date system is
effectively rubbish, and JodaTime isn't yet standard.
I suspect the only way forward for the moment is to quote the date
string as a parameter or use the full no space ISO 8601 format (i.e.
replace space with T), and then ship the string to a JodaTime function
for parsing.
--
Russel.
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077
signature.asc
Description: This is a digitally signed message part
RE: Common CLi Usage
Hi russel,
Thanks for your reply, much appreciated..
If I can change the date/time format to a format where it is only one
string
what will be java syntax for definign the option within my application
e.g
inal Option persistDataOption =
OptionBuilder.withArgName("persist").hasOptionalArgs(3)
hasArg().withDescription("Persist Data with Scheduling")
.create("-p");
I cant seem to get the above line correct...
I want to define an option that has
A. 3 options... name> | | mailto:[EMAIL PROTECTED]
Sent: 29 May 2008 20:25
To: Commons Users List
Subject: Re: Common CLi Usage
* PGP Signed by an unknown key: 05/29/2008 at 09:24:30 PM On Thu,
2008-05-29 at 12:58 +0200, John O'Sullivan wrote:
> myApp -p [ | | ] -a XXX -d xxx -f XXX
>
> where time is of the format '-MM-DD HH:MM:SS'
> Note
> 1. There is a space between the "-MM-DD" and the "HH:MM:SS"(does
> this mean the CLI Parser will see 2 parameters ) 2. The and
> parameters are optional.
> 3. The parameter is mandatory when using the -p option
>
> I am using the Commons Cli API..
> I am trying to define the option as follows but this obviously isnt
> correct
>
> final Option persistDataOption =
> OptionBuilder.withArgName("persist").hasOptionalArgs(3)
> hasArg().withDescription("Persist Data with Scheduling")
> .create(CLIOption.PERSIST_DATA.getOptionString());
> where
> CLIOption.PERSIST_DATA.getOptionString()) will return the "-p" option
>
> Can someone please show me how to define this command line option
> correctly please
I don't have an immediate answer for you I'm afraid. The reason for
replying is to note that this looks almost, but not quite exactly, like
an ISO 8601 date -- the differences are going to be very irritating I
suspect. The though struck me that ISO 8601 date should be a known
construct to any CLI system. Of course, Java's current date system is
effectively rubbish, and JodaTime isn't yet standard.
I suspect the only way forward for the moment is to quote the date
string as a parameter or use the full no space ISO 8601 format (i.e.
replace space with T), and then ship the string to a JodaTime function
for parsing.
--
Russel.
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077
* Unknown Key
* 0x856F058D
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common CLi Usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John, John O'Sullivan wrote: | If I can change the date/time format to a format where it is only one | string | what will be java syntax for definign the option within my application Sorry to poke my nose into what looks like a rather long-running discussion, but it occurs to me that calling your program from the command-line with quotes around the entire timestamp (both date and time) would make the entire parameter appear as one -- with or without the space. Something like: | myApp -p [ | | ] -a XXX -d xxx -f XXX myApp -p '2008-05-29 16:54:25' Does that help you with your "space" problem? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg/GDMACgkQ9CaO5/Lv0PAtuwCeKz11MAM2KultB/c8664q1Mwm rzYAoLQrQs60OzKEP4MFAIOI+bUlGEIl =8QoN -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Common CLi Usage
Hi,
Feel free to poke your nose in anytime ;>
Thanks, thats an idea I will try for the "space problem"..
The Other problem is I dont have the correct syntax for the folowing
line which defines teh option.Do you know the correct java syntax for
this which provides the functionality I require
final Option persistDataOption =
OptionBuilder.withArgName("persist").hasOptionalArgs(3)
hasArg().withDescription("Persist Data with Scheduling")
.create("-p");
This is not correct?
jhon
-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: 29 May 2008 21:55
To: Commons Users List
Subject: Re: Common CLi Usage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John,
John O'Sullivan wrote:
| If I can change the date/time format to a format where it is only one
| string what will be java syntax for definign the option within my
| application
Sorry to poke my nose into what looks like a rather long-running
discussion, but it occurs to me that calling your program from the
command-line with quotes around the entire timestamp (both date and
time) would make the entire parameter appear as one -- with or without
the space. Something like:
| myApp -p [ | | ] -a XXX -d xxx -f XXX
myApp -p '2008-05-29 16:54:25'
Does that help you with your "space" problem?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkg/GDMACgkQ9CaO5/Lv0PAtuwCeKz11MAM2KultB/c8664q1Mwm
rzYAoLQrQs60OzKEP4MFAIOI+bUlGEIl
=8QoN
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common CLi Usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John, John O'Sullivan wrote: | Hi, | Feel free to poke your nose in anytime ;> | | Thanks, thats an idea I will try for the "space problem".. | | The Other problem is I dont have the correct syntax for the folowing | line which defines teh option. Do you know the correct java syntax for | this which provides the functionality I require Heh.. that's the thing... I have no commons-cli experience at all, which makes my nose somewhat unwelcome ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhAhNcACgkQ9CaO5/Lv0PDi+ACeN6o3sgJfUT5WnaBrUaoIVOqS Ui0AoJ/RpEYRw6FwCVKXOF4AjRlP4kDB =cp1f -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Common CLi Usage
John,
On Thu, 2008-05-29 at 22:10 +0200, John O'Sullivan wrote:
> Hi russel,
> Thanks for your reply, much appreciated..
No problem.
If you check the email histories, you'll probably spot that Commons CLI
is a bit of a hobby horse for me. Groovy and Gant both use it but
(unfortunately) it is very broken -- 1.0 just about works, 1.1 has a
collection of great bug fixes thanks to Hen and Brian, but is
fundamentally broken :-(, 2.x got played with and then the development
team evaporated and left the whole package in limbo.
> If I can change the date/time format to a format where it is only one
> string
> what will be java syntax for definign the option within my application
>
> e.g
> inal Option persistDataOption =
> OptionBuilder.withArgName("persist").hasOptionalArgs(3)
> hasArg().withDescription("Persist Data with Scheduling")
> .create("-p");
>
> I cant seem to get the above line correct...
>
> I want to define an option that has
> A. 3 options... name> | | B. 1 Mandatory ... name
> C. 2 optional params Time , Boolean
>
> Can you help me define this option correctly first, then I can move on
> and
> worry about the Date/Time being 2 strings
To be honest I don't think I would even try and attempt using Commons
CLI or any other CLI package to handle the parsing of the option itself.
I would use the options system to get a simple string and then process
that string with a data parser, probably JodaTime until JSR 310 becomes
standard.
So accept "-p" as a simple option with a single string parameter and
then when you find you have one drag up the data processing actions and
handle things then.
--
Russel.
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077
signature.asc
Description: This is a digitally signed message part
RE: [cli] Downloading snapshots
You can try the current RC: http://people.apache.org/builds/commons/cli/1.2/RC7/staged/commons-cli/commons-cli/1.2/ Gary > -Original Message- > From: Roland Roberts [mailto:rol...@astrofoto.org] > Sent: Thursday, March 19, 2009 10:26 AM > To: Commons Users List > Subject: [cli] Downloading snapshots > > It's been a year since I last downloaded a snapshot of commons-cli-2.0, > which I have been happily using, but I thought I would check back for a > newer copy. Unfortunately, my memory is failing, no doubt due to > advancing age and I can't remember (or find) where do get a copy. > > Can someone give me a clue :-/ > > TIA, > > roland > > -- > PGP Key ID: 66 BC 3B CD > Roland B. Roberts, PhD RL Enterprises > rol...@rlenter.com6818 Madeline Court > rol...@astrofoto.org Brooklyn, NY 11220 > > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [cli] Downloading snapshots
Gary Gregory wrote: You can try the current RC: http://people.apache.org/builds/commons/cli/1.2/RC7/staged/commons-cli/commons-cli/1.2/ -Original Message- [...] It's been a year since I last downloaded a snapshot of commons-cli-2.0, Sorry, I'm looking for CLI 2.0. roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises rol...@rlenter.com6818 Madeline Court rol...@astrofoto.org Brooklyn, NY 11220 - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [cli] Downloading snapshots
Hi Roland, deployed the current snapshot to http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-cli/2.0-SNAPSHOT/ Cheers, Siegfried Goeschl Roland Roberts wrote: > Gary Gregory wrote: >> You can try the current RC: >> >> http://people.apache.org/builds/commons/cli/1.2/RC7/staged/commons-cli/commons-cli/1.2/ >> >> >> >>> -Original Message- >>> [...] >>> It's been a year since I last downloaded a snapshot of commons-cli-2.0, >>> > Sorry, I'm looking for CLI 2.0. > > roland > - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [cli] Downloading snapshots
Siegfried Goeschl wrote: deployed the current snapshot to http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-cli/2.0-SNAPSHOT/ Thanks! roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhD RL Enterprises rol...@rlenter.com6818 Madeline Court rol...@astrofoto.org Brooklyn, NY 11220 - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[cli] grouping required options
Hello, my program has a sequence of required options ( o1, o2, o3) and alternative sequence (o4, o5) . I understand that I could put o1 and o4 in the same Option Group as well as o2 and o5 . But how do I tell CLI when to complain for missing o3? And in addition: how do I tell cli not to check for any other option if "help" is passed? bye Thomas - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Commons CLI command stype
Hi, I know the default 'Commons CLI' command style is like ' java -jar ***.jar [OPTIONS]'. Can anyone tell me how to make this kind of command style using Commons CLI? java -jar ***.jar [COMMAND] [OPTIONS] Thanks,
Re: [CLI] - withValueSeparator() usage
I don't think that's how option values works. Option values is basically
like Java prefs: -Dkey=value. I'm a bit surprised it doesn't return b,c as
the value.
I did a blog post here on CLI, maybe the examples are more helpful (full
source linked at the end):
http://www.sop4j.com/2013/01/parsing-command-line.html
Bill-
On Fri, Feb 1, 2013 at 10:03 AM, Greg Thomas wrote:
> I'm struggling on how to use the withValueSeparator() option;
>
> Taking the following piece of code ...
>
> Options options = new Options();
> Option columns = OptionBuilder
> .hasArg()
> .withArgName("CSV columns")
> .withValueSeparator(',')
> .withDescription("Specify the comma separated
> list of columns")
> .create("columns");
> options.addOption(columns);
>
> CommandLineParser parser = new GnuParser();
> CommandLine line = parser.parse(options, new String[]{ "-columns",
> "a,b,c"});
> System.out.println("hasOption:" + line.hasOption("columns"));
> System.out.println("column count:" +
> line.getOptionValues("columns").length);
>
> I woudl expect it to print out something like:
> hasOption:true
> column count:3
>
> whereas in fact I'm getting
> hasOption:true
> column count:1
>
> i.e. despite me specifying ',' as a value separator, getOptionValues() is
> returning a array that is one element in size, containing "a,b,c" instead
> of three elements, each containing a single letter.
>
> I'm missing something - what it is?
>
> Thanks,
>
> Greg
>
Re: [CLI] - withValueSeparator() usage
> I don't think that's how option values works. Option values is basically > like Java prefs: -Dkey=value. I'm a bit surprised it doesn't return b,c as > the value. Doh! Clearly I misunderstood the documentation, I'll simply treat the value as a single string and split() it. Thanks, Greg
Re: [CLI] - withValueSeparator() usage
> Doh! Clearly I misunderstood the documentation, I'll simply treat the value > as a single string and split() it. > Do you think the docs could use some improvement? We're open to contributions/suggestions if that would help. - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [CLI] - withValueSeparator() usage
> Do you think the docs could use some improvement? We're open to > contributions/suggestions if that would help. I'll see if I can have a look at the wording soon, as come up with an alternative suggestion (or if it was just me not paying enough attention!). Greg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [CLI] - withValueSeparator() usage
I've had a look; I the only place that could do with clarification is the javadoc for getOptionValues @ http://commons.apache.org/cli/api-release/org/apache/commons/cli/CommandLine.html#getOptionValues(java.lang.String) / http://commons.apache.org/cli/api-release/org/apache/commons/cli/CommandLine.html#getOptionValues(char) Currently, both say: "Retrieves the array of values, if any, of an option." I'd suggest something like; Where a valueSeparator is used to separate two argument values, these will return both values in an array of length 2. @see OptionBuilder#withValueSeparator() On 2 February 2013 10:48, Greg Thomas wrote: >> Do you think the docs could use some improvement? We're open to >> contributions/suggestions if that would help. > > I'll see if I can have a look at the wording soon, as come up with an > alternative suggestion (or if it was just me not paying enough > attention!). > > Greg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [CLI] - withValueSeparator() usage
On 02/03/2013 06:29 PM, Greg Thomas wrote: > I've had a look; I the only place that could do with clarification is > the javadoc for getOptionValues @ > http://commons.apache.org/cli/api-release/org/apache/commons/cli/CommandLine.html#getOptionValues(java.lang.String) > / > http://commons.apache.org/cli/api-release/org/apache/commons/cli/CommandLine.html#getOptionValues(char) > > Currently, both say: > > "Retrieves the array of values, if any, of an option." > > I'd suggest something like; > > Where a valueSeparator is used to separate two argument values, these > will return both values in an array of length 2. > @see OptionBuilder#withValueSeparator() I think the examples provided in OptionBuilder#withValueSeparator() and OptionBulder#withValueSeparator(char) should be improved to clearly indicate that this separator is only used to distinguish between key and value, and not to split values itself. Thomas - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [CLI] - withValueSeparator() usage
On Sun, Feb 3, 2013 at 9:56 PM, Thomas Neidhart wrote: > On 02/03/2013 06:29 PM, Greg Thomas wrote: > > I've had a look; I the only place that could do with clarification is > > the javadoc for getOptionValues @ > > > http://commons.apache.org/cli/api-release/org/apache/commons/cli/CommandLine.html#getOptionValues(java.lang.String) > > / > http://commons.apache.org/cli/api-release/org/apache/commons/cli/CommandLine.html#getOptionValues(char) > > > > Currently, both say: > > > > "Retrieves the array of values, if any, of an option." > > > > I'd suggest something like; > > > > Where a valueSeparator is used to separate two argument values, these > > will return both values in an array of length 2. > > @see OptionBuilder#withValueSeparator() > > I think the examples provided in OptionBuilder#withValueSeparator() and > OptionBulder#withValueSeparator(char) should be improved to clearly > indicate that this separator is only used to distinguish between key and > value, and not to split values itself. > I did look further into this issue, and The value separator is only used in the Option#processValue method and is indeed used to split the argument into multiple values. Now, the splitting is only performed if in the OptionBuilder, the hasArgs() is specified with the number of expected argument values. With the default setting of hasArg(), like in the example above, no splitting will be performed. The example above also worked, because the option and arguments are separated by whitespace and thus provided as separate tokens to the parser. In this case, the argument is always the next token, regardless of the separator. If you would specify hasArgs(3), you would indeed get the values split into an array of 3 strings. Thomas
Re: [CLI] - withValueSeparator() usage
> If you would specify hasArgs(3), you would indeed get the values > split into an array of 3 strings. Though in my usage, the argument was a CSV list of arbitrary length, the example I gave just happened to be three. Greg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [CLI] - withValueSeparator() usage
On Tue, Feb 5, 2013 at 10:27 AM, Greg Thomas wrote: > > If you would specify hasArgs(3), you would indeed get the values > > split into an array of 3 strings. > > Though in my usage, the argument was a CSV list of arbitrary length, > the example I gave just happened to be three. > Well, I do not think this parameter was intended for dynamic sized arguments, but rather for fixed-size key/value pairs. The documentation clearly lacks in explaining what this parameter does, your use-case would be an extension imho (e.g. allow unlimited arg values). Thomas
Re: [CLI] - withValueSeparator() usage
On Tue, 5 Feb 2013 11:33:45 +0100, Thomas Neidhart wrote: On Tue, Feb 5, 2013 at 10:27 AM, Greg Thomas wrote: > If you would specify hasArgs(3), you would indeed get the values > split into an array of 3 strings. Though in my usage, the argument was a CSV list of arbitrary length, the example I gave just happened to be three. Well, I do not think this parameter was intended for dynamic sized arguments, but rather for fixed-size key/value pairs. The documentation clearly lacks in explaining what this parameter does, your use-case would be an extension imho (e.g. allow unlimited arg values). https://issues.apache.org/jira/browse/CLI-219 Gilles - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [CLI] - withValueSeparator() usage
On 02/05/2013 11:55 AM, Gilles wrote:
> On Tue, 5 Feb 2013 11:33:45 +0100, Thomas Neidhart wrote:
>> On Tue, Feb 5, 2013 at 10:27 AM, Greg Thomas
>> wrote:
>>
>>> > If you would specify hasArgs(3), you would indeed get the values
>>> > split into an array of 3 strings.
>>>
>>> Though in my usage, the argument was a CSV list of arbitrary length,
>>> the example I gave just happened to be three.
>>>
>>
>> Well, I do not think this parameter was intended for dynamic sized
>> arguments, but rather for fixed-size key/value pairs.
>> The documentation clearly lacks in explaining what this parameter does,
>> your use-case would be an extension imho (e.g. allow unlimited arg
>> values).
>>
>
> https://issues.apache.org/jira/browse/CLI-219
Looking at another issue, this seems to be already working, see the
excerpt from a unit test:
options.addOption(OptionBuilder.withValueSeparator(':').hasArgs().create('p'));
String[] args = new String[]
{"-DJAVA_HOME=/opt/java","-pfile1:file2:file3" };
String[] values = cmd.getOptionValues('p');
values is then an array with 3 elements.
So instead of hasArg(), if you call hasArgs() the number of expected
arguments is unlimited.
Thomas
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [CLI] - withValueSeparator() usage
> If you would specify hasArgs(3), you would indeed get the values > split into an array of 3 strings. Though in my usage, the argument was a CSV list of arbitrary length, the example I gave just happened to be three. Well, I do not think this parameter was intended for dynamic sized arguments, but rather for fixed-size key/value pairs. The documentation clearly lacks in explaining what this parameter does, your use-case would be an extension imho (e.g. allow unlimited arg values). https://issues.apache.org/jira/browse/CLI-219 Looking at another issue, this seems to be already working, Unless my very old patch has been applied without being acknowledged on JIRA, I doubt that _that_ problem is solved (cf. the discussion on JIRA -- hint: "[...] if the number of arguments isn't fixed this will aggregate the remaining arguments arg1 and arg2 [...]"). [...] Gilles - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [CLI] - withValueSeparator() usage
On 02/06/2013 12:35 PM, Gilles wrote: >>>> >>>>> > If you would specify hasArgs(3), you would indeed get the values >>>>> > split into an array of 3 strings. >>>>> >>>>> Though in my usage, the argument was a CSV list of arbitrary length, >>>>> the example I gave just happened to be three. >>>>> >>>> >>>> Well, I do not think this parameter was intended for dynamic sized >>>> arguments, but rather for fixed-size key/value pairs. >>>> The documentation clearly lacks in explaining what this parameter does, >>>> your use-case would be an extension imho (e.g. allow unlimited arg >>>> values). >>>> >>> >>> https://issues.apache.org/jira/browse/CLI-219 >> >> Looking at another issue, this seems to be already working, > > Unless my very old patch has been applied without being acknowledged on > JIRA, > I doubt that _that_ problem is solved (cf. the discussion on JIRA -- hint: > "[...] if the number of arguments isn't fixed this will aggregate the > remaining > arguments arg1 and arg2 [...]"). I did not say that your issue is working, but the problem of the original poster wrt splitting of argument values. I should not have responded to your post, this just leads to pointless discussions ... Thomas - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [CLI] - withValueSeparator() usage
> the problem of the > original poster wrt splitting of argument values. It does indeed seem to solve that, so many thanks. Though this has re-enforced my opinion that the doc's need a little tweaking in this area to make it clearer. I'll raise a JIRA to cover it off, I think. Greg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [cli] Submiting patches
Patches to what Sent via mobie On Apr 17, 2016 22:28, "Isuranga Perera" wrote: > Can anybody tell me how to submit my patches. > > Thank You, > Isuranga Perera >
Re: [cli] Submiting patches
Hello, if you have a concerete bug you should open a JIRA ticket and attach your fix (first search if the ticket already exists). If you want to discuss the direction your patch is taking, it is better to write a note to dev@commons "I am working on CLI-x and would like to submit a patch which does x". You can also sent small patches to the dev mailinglist or open a Github PR. It is described here: https://github.com/apache/commons-cli/blob/trunk/CONTRIBUTING.md Thanks for considering to contribute. Gruss Bernd Am Sun, 17 Apr 2016 22:38:43 +0700 schrieb Nayana Hettiarachchi : > Patches to what > > Sent via mobie > On Apr 17, 2016 22:28, "Isuranga Perera" > wrote: > > > Can anybody tell me how to submit my patches. > > > > Thank You, > > Isuranga Perera > > > - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Commons Cli Grouping Query
I'm having some issues working out if commons-cli out of the box can handle my use case or if I'll need to handle it myself. simply program, with a feature which at startup randomly decides if it's enabled this execution. The feature can be specifically disabled or enabled, but if enabled using the -yes switch, it has and optional argument yesOptionalValue. If -yes is present then either -alpha or -bravo is required but not both. $ program [ -help | [ -no | [ -yes | [ -alpha | -bravo ] ] ] ] hope that is understandable. if think what I'm trying to achieve is beyond commons-cli. e.g. full list of valid command lines $ program -help $ program -no $ program -yes -alpha alphaValue $ program -yes -bravo $ program -yes optionalValue -alpha alphaValue $ program -yes optionalValue -bravo others combination are invalid. cheers, john - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
commons-cli 1.1 mutliple arguments
Hi!
At the moment I am trying add commons-cli 1.1 to a small application,
but I have a small problem with it.
I used the code shown on the example page:
Option property = OptionBuilder.withArgName( "property=value" )
.hasArg()
.withValueSeparator()
.withDescription( "use value for given
property" )
.create( "D" );
But when I give the program the following arguments:
java -jar test.jar -Dvalue=key -Dnextvalue=newkey -Dhello=world
I only geht the first value=key pair. Even when using
getOptionValues("D") .
Any suggestions?
Thanks,
Bodo
--
http://www.tvbrowser.org
http://www.wannawork.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release of commons-cli?
CLI 2.0 I don't see any time soon (ever) unless someone gets a big urge. CLI 1.2 I have on my list as a 'sometime soon' along with the next Collections 3.x and Codec 1.x - looking at it I think it could go very easily, none of the 4 tickets are blocked (ignoring that CLI-137 is a painful one to close as WONTFIX). Hen On Tue, May 27, 2008 at 7:39 AM, Mike DeLaurentis <[EMAIL PROTECTED]> wrote: > Are there any plans to release either 1.2 or 2.0 of commons-cli? I'm > particularly interested in the fix for CLI-155. The issue is fixed in the > head for 1.x and seems to be a non-issue in 2.x. There was a patch attached > to the Jira issue, but I'd like to be able to depend on a non-patched > version. When is the next time a release is planned for either of those > branches? > > > Thanks, > > Mike DeLaurentis > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release of commons-cli?
On Tue, 2008-05-27 at 23:54 -0700, Henri Yandell wrote: > CLI 2.0 I don't see any time soon (ever) unless someone gets a big urge. What is needed to move 2.0 to release? Given that the policy decision was made to shift any new activity to 2.0, saying 2.0 is defunct is equivalent to saying Commons CLI is defunct. Can I suggest that 2.0-SNAPSHOT could happily be released into the snapshot repository to give things a kick start? Alternatively, the decision to move to 2.0 could be rescinded and 1.x treated as the mainline. However, I had understood that the 1.x architecture was fundamentally inferior to the 2.x architecture. > CLI 1.2 I have on my list as a 'sometime soon' along with the next > Collections 3.x and Codec 1.x - looking at it I think it could go very > easily, none of the 4 tickets are blocked (ignoring that CLI-137 is a > painful one to close as WONTFIX). I think there is more to CLI-137 than is currently listed. From memory (I will try and dig up the test cases) processing multiple options (e.g. -D) fails to work in CLI 1.1. So unless someone has fixed that I would deem 1.2 as unusable just as 1.1 is :-( This is actually an opportune moment for something to happen with COmmons CLI as there are gumblings again about still having to use CLI 1.0 for Groovy. Current favourite is to switch to a new CLI package that has some energy, i.e. someone is actually working on it :-) Currently mooted to move to are JSAP or JOpt. If however there was a Commons CLI 1.2 and it fixed the bugs we found in the Groovy project that mean that 1.1 is basically broken and unusable, then that would be great. Shifting a version of a package is easier than shifting packages. -- Russel. Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077 signature.asc Description: This is a digitally signed message part
Re: Release of commons-cli?
On Wed, May 28, 2008 at 12:30 AM, Russel Winder <[EMAIL PROTECTED]> wrote: > On Tue, 2008-05-27 at 23:54 -0700, Henri Yandell wrote: >> CLI 2.0 I don't see any time soon (ever) unless someone gets a big urge. > > What is needed to move 2.0 to release? Given that the policy decision > was made to shift any new activity to 2.0, saying 2.0 is defunct is > equivalent to saying Commons CLI is defunct. No life happened on 2.0. I've been applying patches that show up for the 1.x branch, just because. :) > Can I suggest that > 2.0-SNAPSHOT could happily be released into the snapshot repository to > give things a kick start? I'll get that done. Been a while since I remember doing a snapshot release so have asked how we do that nowadays on [EMAIL PROTECTED] > Alternatively, the decision to move to 2.0 could be rescinded and 1.x > treated as the mainline. However, I had understood that the 1.x > architecture was fundamentally inferior to the 2.x architecture. That's what they say. As a user I didn't feel too excited about the 2.x API. >> CLI 1.2 I have on my list as a 'sometime soon' along with the next >> Collections 3.x and Codec 1.x - looking at it I think it could go very >> easily, none of the 4 tickets are blocked (ignoring that CLI-137 is a >> painful one to close as WONTFIX). > > I think there is more to CLI-137 than is currently listed. From memory > (I will try and dig up the test cases) processing multiple options (e.g. > -D) fails to work in CLI 1.1. So unless someone has fixed that I would > deem 1.2 as unusable just as 1.1 is :-( Test cases much appreciated :) > This is actually an opportune moment for something to happen with > COmmons CLI as there are gumblings again about still having to use CLI > 1.0 for Groovy. Current favourite is to switch to a new CLI package > that has some energy, i.e. someone is actually working on it :-) > Currently mooted to move to are JSAP or JOpt. > > If however there was a Commons CLI 1.2 and it fixed the bugs we found in > the Groovy project that mean that 1.1 is basically broken and unusable, > then that would be great. Shifting a version of a package is easier > than shifting packages. I don't see why not for a 1.2 release that fixed the bugs. All I got from the previous problems was that unfortunately .hasArg had to be changed to .hasArgs, so more test cases for the problems would be great. I was focused on JIRA issues rather than the mailing list archives though. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release of commons-cli?
Hen, On Wed, 2008-05-28 at 02:01 -0700, Henri Yandell wrote: > On Wed, May 28, 2008 at 12:30 AM, Russel Winder > > What is needed to move 2.0 to release? Given that the policy decision > > was made to shift any new activity to 2.0, saying 2.0 is defunct is > > equivalent to saying Commons CLI is defunct. > > No life happened on 2.0. I've been applying patches that show up for > the 1.x branch, just because. :) I think this is a chicken and egg problem. No-one is doing anything proactive at the minute because the Commons CLI development team is the empty set. No-one is providing bug reports for 2.x because 2.0 is not publicly available in any form. It is good that you are doing the 1.x patching, but I think a bit of decisive management is in order. For me the options would appear to be: 1. Declare Commons CLI end of life and let it gently disappear. People will then move to those projects that have activity. 2. Declare Commons CLI 2.x the active branch -- even to renaming the package to cli instead of cli2, put out a snapshot so people can use it and provide bug reports, nominate a couple of the volunteers to the development team -- basically use the little interest there is in CLI to boostrap a more lively community. Oh and schedule a putative release date for 2.0 and publicize it so that an RC programme can be started. 3. Declare Commons CLI 2.x a dead branch, revert to 1.x as the only line of development, make a Maven 2 build for it. Then do exactly the same as above, get the few volunteers into a formal development team, announce a release date and begin an RC programme. Sorry if I am being a bit over-pushy here but the Commons CLI 1.0 issue is really annoying a few of the Groovy developers. > > Can I suggest that > > 2.0-SNAPSHOT could happily be released into the snapshot repository to > > give things a kick start? > > I'll get that done. Been a while since I remember doing a snapshot > release so have asked how we do that nowadays on [EMAIL PROTECTED] I have no idea about the Apache system but at Codehaus deployments go to the snapshot repository automatically if the version number has -SNAPSHOT at the end. For the Gant project (which let's be honest is the only one I actually know about), it all Just Works (tm). > > Alternatively, the decision to move to 2.0 could be rescinded and 1.x > > treated as the mainline. However, I had understood that the 1.x > > architecture was fundamentally inferior to the 2.x architecture. > > That's what they say. As a user I didn't feel too excited about the 2.x API. If there is a compelling reason for the 1.x -> 2.x API change, is there a document somewhere that explains it? Or is the information trapped in the heads of the development team who fled the project? I can do a little to do some analysis and recommendation but not masses. It would actually be interesting to know why the 2.x developers effectively abandoned the project. > > I think there is more to CLI-137 than is currently listed. From memory > > (I will try and dig up the test cases) processing multiple options (e.g. > > -D) fails to work in CLI 1.1. So unless someone has fixed that I would > > deem 1.2 as unusable just as 1.1 is :-( > > Test cases much appreciated :) I'll have a look tomorrow to see if I can turn all my rantings and bad examples into some proper test cases. > > > This is actually an opportune moment for something to happen with > > COmmons CLI as there are gumblings again about still having to use CLI > > 1.0 for Groovy. Current favourite is to switch to a new CLI package > > that has some energy, i.e. someone is actually working on it :-) > > Currently mooted to move to are JSAP or JOpt. > > > > If however there was a Commons CLI 1.2 and it fixed the bugs we found in > > the Groovy project that mean that 1.1 is basically broken and unusable, > > then that would be great. Shifting a version of a package is easier > > than shifting packages. > > I don't see why not for a 1.2 release that fixed the bugs. All I got > from the previous problems was that unfortunately .hasArg had to be > changed to .hasArgs, so more test cases for the problems would be > great. I was focused on JIRA issues rather than the mailing list > archives though. There is the problem behind that that there seemed to be errors in the implementation which meant that multiple option occurrences actually caused total chaos. Also the PosixParser and GnuParser both behave differently to what the documentation says they should do. Again I have rants but I need to turn them into test cases. I have to admit I got bored with trying to sort it all out when I realized I was totally on my own trying to sort it out. All the Groovy guys just want to abandon Comm
Re: Release of commons-cli?
Henri Yandell wrote:
CLI 2.0 I don't see any time soon (ever) unless someone gets a big urge.
CLI 1.2 I have on my list as a 'sometime soon' along with the next
Collections 3.x and Codec 1.x - looking at it I think it could go very
easily, none of the 4 tickets are blocked (ignoring that CLI-137 is a
painful one to close as WONTFIX).
[...]
I have done some work on CLI-137 as part of the Debian packaging. I
think it is quite a severe bug, as it does not allow you to handle (for
example) multiple "-D" arguments (as found in Maven or ant).
I've prepared a patch for it for the Debian build (although I do not
necessarily think that's the best way to fix it), and amended the JUnit
tests to demonstrate the problem.
I sent an email to the -dev list a few weeks ago, but I think it might
have gone missing. Here it is:
Hi,
I've fallen over the CLI bug described in issue 137, and I'm wondering
if I can help provide a patch for it? I'd appreciate someone just
checking my logic in case I'm missing something obvious. I'm using
release 1.1, by the way.
As far as I can see it is simply not possible to use commons-cli to
parse repeating options, such as occur in ant:
ant -Dproperty1=value1 -Dproperty2=value2 compile
Cli *does* have a junit test for ant-type options, but it unfortunately
doesn't catch the error because it tests the command line:
ant -Dproperty1=value1 -Dproperty2=value2 -projecthelp
I attach a patch for the junit test (Cli-junit.patch) that will provoke
the error, if you want to try it yourself.
_Here's what I think is happening:_
The unit test (and the work-around suggested in issue 137) creates the
"D" option using "hasArgs()" [note the 's' on the end of the method
name]. Using hasArgs() for the "D" option causes cli to assume that all
arguments following the "-D" (until it encounters another option) belong
to the "-D" option. I've probably not explained that clearly so here's
an example:
ant -Dproperty1=value1 -Dproperty2=value2 compile
will treat "compile" as though it was "-Dcompile". getArgs() will return
0 elements, rather than one ("compile").
If instead you construct the "D" option using hasArg() [singular] then
it will *not* interpret the second "-D" as an option. getArgs() will
return 2 elements: "property2=value2" and "compile". getOptionValues()
will return only the first -D value.
This problem first came to light when Debian upgraded CLI from 1.0 to
1.1, and caused Debian's Maven package to fail (the standard Maven
package uses cli 1.0 of course). As part of the Debian packaging I have
created a quick-and-dirty patch which allows Maven to work (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469082 for the Debian
bug report, and I have attached the patch (MultiOptions.patch). I would
guess that a proper fix would be rather more elegant than my patch.
Thanks,
Paul Cager
Index: src/test/org/apache/commons/cli/ApplicationTest.java
===
--- src/test/org/apache/commons/cli/ApplicationTest.java(revision
635884)
+++ src/test/org/apache/commons/cli/ApplicationTest.java(working copy)
@@ -96,15 +96,16 @@
options.addOption( "listener", true, "add an instance of a class as a
project listener" );
options.addOption( "buildfile", true, "use given buildfile" );
options.addOption( OptionBuilder.withDescription( "use value for given
property" )
-.hasArgs()
+.hasArgs(1)
.withValueSeparator()
.create( 'D' ) );
//, null, true, , false, true );
options.addOption( "find", true, "search for buildfile towards the
root of the filesystem and use it" );
String[] args = new String[]{ "-buildfile", "mybuild.xml",
+"-projecthelp",
"-Dproperty=value", "-Dproperty1=value1",
-"-projecthelp" };
+"compile" };
try {
CommandLine line = parser.parse( options, args );
@@ -121,6 +122,7 @@
// check option
assertTrue( line.hasOption( "projecthelp") );
+ assertEquals(1, line.getArgs().length);
}
catch( ParseException exp ) {
fail( "Unexpected exception:" + exp.getMessage() );
@@ -128,4 +130,4 @@
}
-}
\ No newline at end of file
+}
Index: src/java/org/apache/commons/cli/Option.java
===
Re: Release of commons-cli?
Paul,
On Wed, 2008-05-28 at 21:27 +0100, Paul Cager wrote:
> I have done some work on CLI-137 as part of the Debian packaging. I
> think it is quite a severe bug, as it does not allow you to handle (for
> example) multiple "-D" arguments (as found in Maven or ant).
Exactly. For the Groovy and Gant projects, this is not so much severe
as a complete blocker. We upgraded 1.0 -> 1.1, made changes for the
hasArg(s) problems and still nothing about multiple options worked.
Worse all the non option parameters were absorbed into the options
processing.
> I've prepared a patch for it for the Debian build (although I do not
> necessarily think that's the best way to fix it), and amended the JUnit
> tests to demonstrate the problem.
>
> I sent an email to the -dev list a few weeks ago, but I think it might
> have gone missing. Here it is:
I certainly saw the email and was hoping there would be a response. I
appreciate Hen is trying his best to keep Commons CLI ticking over, but
it really needs someone with commit access to take ownership of the
Commons CLI package.
Step 1 for me is to give the 1.x branch a Maven 2 build. I will take a
Bazaar branch and see if dropping the POM from trunk in and editing
suitably does the trick.
> I've fallen over the CLI bug described in issue 137, and I'm wondering
> if I can help provide a patch for it? I'd appreciate someone just
> checking my logic in case I'm missing something obvious. I'm using
> release 1.1, by the way.
I'm afraid I haven't checked your ideas myself yet. I'll try and get to
it tomorrow.
> As far as I can see it is simply not possible to use commons-cli to
> parse repeating options, such as occur in ant:
>
> ant -Dproperty1=value1 -Dproperty2=value2 compile
>
> Cli *does* have a junit test for ant-type options, but it unfortunately
> doesn't catch the error because it tests the command line:
>
> ant -Dproperty1=value1 -Dproperty2=value2 -projecthelp
>
> I attach a patch for the junit test (Cli-junit.patch) that will provoke
> the error, if you want to try it yourself.
>
>
> _Here's what I think is happening:_
>
> The unit test (and the work-around suggested in issue 137) creates the
> "D" option using "hasArgs()" [note the 's' on the end of the method
> name]. Using hasArgs() for the "D" option causes cli to assume that all
> arguments following the "-D" (until it encounters another option) belong
> to the "-D" option. I've probably not explained that clearly so here's
> an example:
>
> ant -Dproperty1=value1 -Dproperty2=value2 compile
>
> will treat "compile" as though it was "-Dcompile". getArgs() will return
> 0 elements, rather than one ("compile").
Exactly. The semantics behind the option processing is just broken. I
agree that it can be seen that the 1.0 meaning of hasArg(s) is wrong
compared to the 1.1 meaning but using 1.0 there is a way of processing
multiple options, whereas with 1.1 there appears to be no workaround for
the seriously fundamental bug.
> If instead you construct the "D" option using hasArg() [singular] then
> it will *not* interpret the second "-D" as an option. getArgs() will
> return 2 elements: "property2=value2" and "compile". getOptionValues()
> will return only the first -D value.
You experience and my experience are identical I think. Which is of
course as it should be since there is a clear and obvious bug :-)
Clearly there need to be more unit tests in the codebase, and in
particular tests that show that the 1.1 release is actually broken.
Once I have a Bazaar branch of the codebase I will be able to experiment
more to make proper test cases.
> This problem first came to light when Debian upgraded CLI from 1.0 to
> 1.1, and caused Debian's Maven package to fail (the standard Maven
> package uses cli 1.0 of course). As part of the Debian packaging I have
> created a quick-and-dirty patch which allows Maven to work (see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469082 for the Debian
> bug report, and I have attached the patch (MultiOptions.patch). I would
> guess that a proper fix would be rather more elegant than my patch.
On the other hand if your patch makes this work, then it is infinitely
better that the current situation which is that 1.1. is unusable.
--
Russel.
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077
signature.asc
Description: This is a digitally signed message part
Re: Release of commons-cli?
On Wed, May 28, 2008 at 9:01 AM, Russel Winder <[EMAIL PROTECTED]> wrote: > Hen, > > On Wed, 2008-05-28 at 02:01 -0700, Henri Yandell wrote: >> On Wed, May 28, 2008 at 12:30 AM, Russel Winder >> > What is needed to move 2.0 to release? Given that the policy decision >> > was made to shift any new activity to 2.0, saying 2.0 is defunct is >> > equivalent to saying Commons CLI is defunct. >> >> No life happened on 2.0. I've been applying patches that show up for >> the 1.x branch, just because. :) > > I think this is a chicken and egg problem. No-one is doing anything > proactive at the minute because the Commons CLI development team is the > empty set. No-one is providing bug reports for 2.x because 2.0 is not > publicly available in any form. > > It is good that you are doing the 1.x patching, but I think a bit of > decisive management is in order. For me the options would appear to be: > > 1. Declare Commons CLI end of life and let it gently disappear. People > will then move to those projects that have activity. Tempting. Commons has a few libraries that are similarly commonly used and reaching end of life; BeanUtils jumps to mind as a popular yet EOL library. > 2. Declare Commons CLI 2.x the active branch -- even to renaming the > package to cli instead of cli2, put out a snapshot so people can use it > and provide bug reports, nominate a couple of the volunteers to the > development team -- basically use the little interest there is in CLI to > boostrap a more lively community. Oh and schedule a putative release > date for 2.0 and publicize it so that an RC programme can be started. Snapshot done: http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-cli/ Package renaming to cli is unlikely to happen. CLI2 is the active branch now, in terms of declaration, just not in reality. > 3. Declare Commons CLI 2.x a dead branch, revert to 1.x as the only > line of development, make a Maven 2 build for it. Then do exactly the > same as above, get the few volunteers into a formal development team, > announce a release date and begin an RC programme. > > Sorry if I am being a bit over-pushy here but the Commons CLI 1.0 issue > is really annoying a few of the Groovy developers. No prob - I really hadn't grokked the -D bug until the last email. We need to get that fixed. > If there is a compelling reason for the 1.x -> 2.x API change, is there > a document somewhere that explains it? Or is the information trapped in > the heads of the development team who fled the project? I can do a > little to do some analysis and recommendation but not masses. Trapped. > It would actually be interesting to know why the 2.x developers > effectively abandoned the project. Yep. Maybe time for an email, it's been a while since I sent them one. > I have to admit I got bored with trying to sort it all out when I > realized I was totally on my own trying to sort it out. All the Groovy > guys just want to abandon Commons CLI in favour of a package that has > some active development or at least maintenance. An active programme to > release Commons CLI 1.2 and 1.3 would be a boon and save us a lot of > hassle and work. Maintenance releases here are reactive - ie) there's no reason for a 1.3 yet as all bugs should be fixable in a 1.2 release. > Switching to 2.0 is predicated on 2.1 being scheduled > and 2.0-SNAPSHOT hitting the Maven repository. 2.0 schedule = when all bugs in the 2.0 JIRA project are resolved or moved to 2.1. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release of commons-cli?
On Thu, 2008-05-29 at 08:50 -0700, Henri Yandell wrote: > > 1. Declare Commons CLI end of life and let it gently disappear. People > > will then move to those projects that have activity. > > Tempting. Commons has a few libraries that are similarly commonly used > and reaching end of life; BeanUtils jumps to mind as a popular yet EOL > library. Or alternatively there are at least 4 people all of a sudden very active -- quick co-opt them, form a team :-) I am currently in the process of getting a Bazaar branch so I can work on the source without suffering Subversion. However with 660,000+ revisions it is going to take a few days. To be honest I am thinking of exporting the Subversion store and ignoring history, 660,000+ revisions is too many for any project. > > 2. Declare Commons CLI 2.x the active branch -- even to renaming the > > package to cli instead of cli2, put out a snapshot so people can use it > > and provide bug reports, nominate a couple of the volunteers to the > > development team -- basically use the little interest there is in CLI to > > boostrap a more lively community. Oh and schedule a putative release > > date for 2.0 and publicize it so that an RC programme can be started. > > Snapshot done: > > http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-cli/ Excellent, thanks. This actually gives the option of not worrying about 1.2 ;-) > Package renaming to cli is unlikely to happen. CLI2 is the active > branch now, in terms of declaration, just not in reality. OK, cli2 is fine despite having a 2 too many. > > 3. Declare Commons CLI 2.x a dead branch, revert to 1.x as the only > > line of development, make a Maven 2 build for it. Then do exactly the > > same as above, get the few volunteers into a formal development team, > > announce a release date and begin an RC programme. > > > > Sorry if I am being a bit over-pushy here but the Commons CLI 1.0 issue > > is really annoying a few of the Groovy developers. > > No prob - I really hadn't grokked the -D bug until the last email. We > need to get that fixed. It really is a total blocker. I am hoping that 2.0-SNAPSHOT fails to exhibit the problem. > > If there is a compelling reason for the 1.x -> 2.x API change, is there > > a document somewhere that explains it? Or is the information trapped in > > the heads of the development team who fled the project? I can do a > > little to do some analysis and recommendation but not masses. > > Trapped. > > > It would actually be interesting to know why the 2.x developers > > effectively abandoned the project. > > Yep. Maybe time for an email, it's been a while since I sent them one. To be honest, the single most important question for me is: Why did you stop work on Commons CLI? > > I have to admit I got bored with trying to sort it all out when I > > realized I was totally on my own trying to sort it out. All the Groovy > > guys just want to abandon Commons CLI in favour of a package that has > > some active development or at least maintenance. An active programme to > > release Commons CLI 1.2 and 1.3 would be a boon and save us a lot of > > hassle and work. > > Maintenance releases here are reactive - ie) there's no reason for a > 1.3 yet as all bugs should be fixable in a 1.2 release. OK, that works for me if it is a public policy. > > Switching to 2.0 is predicated on 2.1 being scheduled > > and 2.0-SNAPSHOT hitting the Maven repository. > > 2.0 schedule = when all bugs in the 2.0 JIRA project are resolved or > moved to 2.1. So this just needs a critical mass. 2.x is supposedly a huge improvement over 1.x. 2.x is supposed to have all the niggles of 1.x resolved and removed. If everyone who has recently shown interest in 1.x would be prepared to investigate 2.x then a concerted effort could be made to turn 2.0-SNAPSHOT into 2.0, this would then probably cause a huge move from 1.0 to 2.0. I guess what we need is a metronome email to make sure people keep working on things. -- Russel. Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077 signature.asc Description: This is a digitally signed message part
Re: Release of commons-cli?
Russel Winder wrote: Paul, On Wed, 2008-05-28 at 21:27 +0100, Paul Cager wrote: I have done some work on CLI-137 as part of the Debian packaging. I think it is quite a severe bug, as it does not allow you to handle (for example) multiple "-D" arguments (as found in Maven or ant). Exactly. For the Groovy and Gant projects, this is not so much severe as a complete blocker. We upgraded 1.0 -> 1.1, made changes for the hasArg(s) problems and still nothing about multiple options worked. Worse all the non option parameters were absorbed into the options processing. I've prepared a patch for it for the Debian build (although I do not necessarily think that's the best way to fix it), and amended the JUnit tests to demonstrate the problem. I sent an email to the -dev list a few weeks ago, but I think it might have gone missing. Here it is: I certainly saw the email and was hoping there would be a response. I appreciate Hen is trying his best to keep Commons CLI ticking over, but it really needs someone with commit access to take ownership of the Commons CLI package. Step 1 for me is to give the 1.x branch a Maven 2 build. I will take a Bazaar branch and see if dropping the POM from trunk in and editing suitably does the trick. I've checked in a working Maven 2 POM in the 1.x branch. It is missing the assembly bits, but we can look at that later on. Let me know if it needs anything more. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release of commons-cli?
On Thu, 2008-05-29 at 23:06 +0200, Dennis Lundberg wrote: > I've checked in a working Maven 2 POM in the 1.x branch. It is missing > the assembly bits, but we can look at that later on. Let me know if it > needs anything more. Splendid, thanks. I can now build CLI 1.x :-) I guess it might be wise to retire the Maven 1 build files? Now I just have to wait for Bazaar to finish building a branch of the CLI 1.x and CLI Trunk branches -- it is a long waiting job on a Subversion repository with 660,000 revisions ! -- Russel. Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077 signature.asc Description: This is a digitally signed message part
Re: Release of commons-cli?
On Thu, May 29, 2008 at 11:01 PM, Russel Winder <[EMAIL PROTECTED]> wrote: > On Thu, 2008-05-29 at 23:06 +0200, Dennis Lundberg wrote: > >> I've checked in a working Maven 2 POM in the 1.x branch. It is missing >> the assembly bits, but we can look at that later on. Let me know if it >> needs anything more. > > Splendid, thanks. I can now build CLI 1.x :-) > > I guess it might be wise to retire the Maven 1 build files? With Lang I kept the Maven1 build until a release had been done with the M2 one. There's "working" and there's "able to generate a correct distribution + website". Of course the website comes from CLI2 for CLI, so that's half of that out of the way :) > Now I just have to wait for Bazaar to finish building a branch of the > CLI 1.x and CLI Trunk branches -- it is a long waiting job on a > Subversion repository with 660,000 revisions ! How horrid :) [he says knowing that one day he needs to pick up bazaar or git or something]. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release of commons-cli?
Hen, On Thu, 2008-05-29 at 23:04 -0700, Henri Yandell wrote: > With Lang I kept the Maven1 build until a release had been done with > the M2 one. There's "working" and there's "able to generate a correct > distribution + website". I understand. It is always wise to have a safety fallback position. On the other hand, this is a VCS so deleting the files doesn't mean they go away, just that you can't use them without delving into the project history. > Of course the website comes from CLI2 for CLI, so that's half of that > out of the way :) Now that we have a CLI2 snapshot in the Maven repository, I will progress looking to see if it solves the problems of CLI 1.0 and CLI 1.1, but it will be next week I'm afraid. > > Now I just have to wait for Bazaar to finish building a branch of the > > CLI 1.x and CLI Trunk branches -- it is a long waiting job on a > > Subversion repository with 660,000 revisions ! > > How horrid :) [he says knowing that one day he needs to pick up bazaar > or git or something]. Unfortunately, Bazaar is failing to get a branch as there appears to be an inconsistency in the Subversion repository at r661567. Jelmer Vernooij (the bzr-svn developer) is aware of this and is going to take a look at it as soon as he can. I guess I could try a Git clone in the interim, but I bet even it would take 10 hours or more to get a clone, and anyway Git is horrible to use compared to Bazaar -- at least for me. Bazaar is so much nicer to use for me, for the way I work. If Jelmer things fixing bzr-svn to deal with the problem in the Subversion repository is going to take a while, I will just export the Subversion directories and create a new Bazaar branch without the previous history. -- Russel. Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077 signature.asc Description: This is a digitally signed message part
[cli] 2.x command line
I must be missing something very simple. . . The 2.x appears to have no way of not processing items on the command line: it seems that in order to parse a command line you have to specify every aspect of the line. This means that a command line such as: foo -q blah where blah is a variable cannot be described. With 1.x this is easy you just specify information about the -q parse the line and then call getArgList to get a list of all the items not recognized. This works well, but seems to have no equivalent in 2.x. -- Russel. Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077 signature.asc Description: This is a digitally signed message part
[cli] Generate all possible commands
Hi All, Is there any way to generate the list of all possible commands from a given command with options? Example, say a command has a syntax: myCmd -option1 [-option2 ] [-option3 ] -option4 . The list of all possible commands would be myCmd -option1 -option4 myCmd -option1 -option2 -option4 myCmd -option1 -option3 -option4 myCmd -option1 -option2 -option3 -option4 Thanks and Regards, Phanindra.
[ANNOUNCE] Commons CLI 1.2 Released
I'd like to announce that Commons CLI 1.2 has been released. Commons CLI provides an API for processing command line interfaces. This is a minor release, containing the last 2 years of bugfixes and minor improvements to the CLI codebase. Full details of this can be found in the release notes: http://commons.apache.org/cli/release_1_2.html The major item of note is an accidental change of behaviour between CLI 1.0 and CLI 1.1 (as noted in CLI-137) that has now been reverted. For more information on Commons CLI, please visit the CLI website: http://commons.apache.org/cli/ The CLI jars have have been uploaded to the Maven repository, and CLI is also available in either binary or source form from: http://commons.apache.org/downloads/download_cli.cgi Henri Yandell on behalf of the Commons community - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[cli]MissingOptionException not being thrown
I am unable to make an option as a required option. This happens when I
use it's 'setRequired' method after getting a handle to the 'Option'
object through the 'Options' object's 'getOption' method.
CODE
"
Options options = new Options();
options.addOption("a1", true, "abcd");
options.getOption("a1").setRequired(true);
boolean caught = false;
try {
CommandLineParser parser = new PosixParser();
CommandLine cmd = parser.parse(options, args);
} catch (ParseException e) {
System.out.println(e);
caught = true;
}
if (!caught)
System.out.println("Not caught");
"
OUTPUT
--
"
java SortCompare
Not caught
"
However if I create an 'Option' object explicitly, call its
'setRequired' method and then add this object to an 'Options' object,
things work fine.
CODE
"
Option opt = new Option("a1", true, "abcd");
opt.setRequired(true);
options.addOption(opt);
try {
CommandLineParser parser = new PosixParser();
CommandLine cmd = parser.parse(options, args);
} catch (ParseException e) {
System.out.println(e);
}
"
OUTPUT
--
"
java SortCompare
org.apache.commons.cli.MissingOptionException: Missing required options: a1
"
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [cli] grouping required options
Hi Thomas, I'm not sure to understand your example. Your command line must either have o1+o2+o3 or o4+o5, right ? Regarding --help, the solution is to have two command line definitions and parsing the arguments twice: first to detect the help option, then for all the arguments supported. Emmanuel Bourg Le 29/11/2011 17:18, Papendieck, Thomas a écrit : Hello, my program has a sequence of required options ( o1, o2, o3) and alternative sequence (o4, o5) . I understand that I could put o1 and o4 in the same Option Group as well as o2 and o5 . But how do I tell CLI when to complain for missing o3? And in addition: how do I tell cli not to check for any other option if "help" is passed? bye Thomas - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org smime.p7s Description: Signature cryptographique S/MIME
AW: [cli] grouping required options
Hello Emmanuel, Thanks for your answer. > Your command line must either > have o1+o2+o3 or o4+o5, right ? Yes. > Regarding --help, the solution is to have two command line definitions > and parsing the arguments twice: first to detect the help option, then > for all the arguments supported. ok, I see. bye thomas - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: Commons CLI command stype
On 01/28/2013 06:08 PM, Eric Liu wrote:
> Hi,
>
> I know the default 'Commons CLI' command style is like ' java -jar
> ***.jar [OPTIONS]'. Can anyone tell me how to make this kind of command
> style using Commons CLI?
>
> java -jar ***.jar [COMMAND] [OPTIONS]
Well, as you already pointed out, Commons CLI currently only supports
additional (or left-over) arguments at the end like this:
java -jar ***.jar [OPTIONS] [COMMAND]
But if you know for sure that the first token will be the command, you
could strip the first argument (after making sure it is not an option),
and only provide the remaining arguments to the parser.
The help text could be manually adjusted like that:
formatter.printHelp("myapp [COMMAND]", header, options, footer, true);
You could also create a feature request in JIRA if you like.
Thomas
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: Commons CLI command stype
*Thanks *Thomas
2013/1/28 Thomas Neidhart
> On 01/28/2013 06:08 PM, Eric Liu wrote:
> > Hi,
> >
> > I know the default 'Commons CLI' command style is like ' java -jar
> > ***.jar [OPTIONS]'. Can anyone tell me how to make this kind of command
> > style using Commons CLI?
> >
> > java -jar ***.jar [COMMAND] [OPTIONS]
>
> Well, as you already pointed out, Commons CLI currently only supports
> additional (or left-over) arguments at the end like this:
>
> java -jar ***.jar [OPTIONS] [COMMAND]
>
> But if you know for sure that the first token will be the command, you
> could strip the first argument (after making sure it is not an option),
> and only provide the remaining arguments to the parser.
>
> The help text could be manually adjusted like that:
>
> formatter.printHelp("myapp [COMMAND]", header, options, footer, true);
>
> You could also create a feature request in JIRA if you like.
>
> Thomas
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>
Commons CLI - possible faulty build
Hi, i was looking for a tool to parse command line arguments in Java and came to Apache Commons CLI. I noticed that using the binary package (commons-cli-1.3.1.jar) from http://www.pirbot.com/mirrors/apache//commons/cli/binaries/commons-cli-1.3.1-bin.tar.gz doesn't work. The program compiles but prints the following error: Exception in thread "main" java.lang.NoSuchMethodError: org.apache.commons.cli.Options.hasShortOption(Ljava/lang/String;)Z at org.apache.commons.cli.DefaultParser.handleShortAndLongOption(DefaultParser.java:490) The jar is in the classpath, it's NOT a classpath issue. Building from source using, all works as expected. You might want to review the binary release. A minor issue i found with the method Option.getArgs(). It's said that "Returns the number of argument values this Option can take." However, if an option doesn't take any value, the return of this method is -1 which seems wrong. Does this sound right? Thanks and best regards Thomas - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[cli] absolute file path parsing
I am using the apache.commons.cli CommandLineParser and am running into the
following problem.
$ java -jar ./target/sorteria-0.0.1-SNAPSHOT-jar-with-dependencies.jar -f
C:\shared\HCPAnywhere\AW001_3.0.0.20.iso -t ISO
test = C:sharedHCPAnywhereAW001_3.0.0.20.iso
File = C:sharedHCPAnywhereAW001_3.0.0.20.iso
When getting the -f option which is going to be an absolute file path the
parser removes the \ character. If I use \\ this works fine
$ java -jar ./target/sorteria-0.0.1-SNAPSHOT-jar-with-dependencies.jar -f
C:\\shared\\HCPAnywhere\\AW001_3.0.0.20.iso -t ISO
test = C:\shared\HCPAnywhere\AW001_3.0.0.20.iso
File = C:\shared\HCPAnywhere\AW001_3.0.0.20.iso
I don't want the end user of this tool to have to know to do this though. Is
there a way for the parser to handle the \ character? Maybe in the creation of
the options? What I have for creating this option is
Option file = new Option("f", "file", true, "Absolute File and Location");
file.setRequired(true);
options.addOption(file);
Roger
roger.cre...@hds.com
Re: using commons cli options
++ Commons Users On Feb 22, 2018 5:43 AM, "Ted Yu" wrote: Hi, In the following project, we try to use commons cli options: addOptWithArg(REGIONSERVER_COUNT_KEY, "Total number of region servers. Default: '" + DEFAULT_REGIONSERVER_COUNT + "'"); https://github.com/apache/hbase/blob/master/hbase-it/ src/test/java/org/apache/hadoop/hbase/IntegrationTestBackupRestore.java#L295 When the following is entered on the command line: -region_servers 1 parser didn't get the value of 1, resulting in default value being used. We currently use commons cli 1.4 I debugged a little in Eclipse with 1.5 but the result is the same. Did I miss something ? Cheers
[ANNOUNCE] Apache Commons CLI 1.5.0
The Apache Commons project announces the release of Apache Commons CLI 1.5.0. Commons CLI requires at least Java 8. The Apache Commons CLI library provides a simple command Line arguments parser. This is a Feature and bug fix release (Java 8) Historical list of changes: https://commons.apache.org/proper/commons-cli/changes-report.html For complete information on Apache Commons CLI, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Apache Commons CLI website: https://commons.apache.org/proper/commons-cli/ Download page: https://commons.apache.org/proper/commons-cli/download_csv.cgi Have fun! - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[ANNOUNCE] Apache Commons CLI 1.5.0
The Apache Commons project announces the release of Apache Commons CLI 1.5.0. Commons CLI requires at least Java 8. The Apache Commons CLI library provides a simple command Line arguments parser. This is a Feature and bug fix release (Java 8) Historical list of changes: https://commons.apache.org/proper/commons-cli/changes-report.html For complete information on Apache Commons CLI, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Apache Commons CLI website: https://commons.apache.org/proper/commons-cli/ Download page: https://commons.apache.org/proper/commons-cli/download_cli.cgi Have fun! - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[cli] Broken 'Javadoc latest' link
Hi everyone, I just wanted to inform people that the 'Javadoc latest' link on the commons-cli about page[1] under Documentation leads to a 404. If there is a more appropriate appropriate place to send this information to, I am not aware of it, since I am unfamiliar with how Apache does things. In that case please tell me where to write to or create the issue. [1]: https://commons.apache.org/proper/commons-cli/ -- Jonas Tobias Hopusch OpenPGP Keys for encrypted communication are available via Web Key Directory (WKD) or from https://downloads.jotoho.de/openpgp/ - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[ANNOUNCE] Apache Commons CLI 1.6.0
The Apache Commons team announces Apache Commons CLI 1.6.0. Apache Commons CLI provides a simple API for working with the command line arguments and options. This release contains small new features and bug fixes Historical list of changes: https://commons.apache.org/proper/commons-cli/changes-report.html For complete information on Apache Commons CLI, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons CLI website: https://commons.apache.org/proper/commons-cli/ Download page: https://commons.apache.org/proper/commons-cli/download_cli.cgi Have fun! Gary Gregory - The Apache Commons Team - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[cli] Cannot combine Option with multiple Values with arguments using Apache Commons CLI V1.2
Hi there,
I'm trying to implement a command line parser using Apache Commons CLI v. 1.2
(unfortunately I am forced to use that version). The syntax to be accepted is
quite simple:
MyProg [ -x path[:path]... ] [ file1 ... ]
Option '-x' should accept a search path like sequence of directories (separated
by ':') optionally followed by zero or more file names. My code looks as
follows:
Option dbPath = OptionBuilder.withLongOpt("db_path")
.withDescription("DB search path")
.hasArgs()
.withValueSeparator(':')
.withArgName("Path[:Path]...")
.create('x');
Options opts = new Options();
opts.addOption(dbPath);
String[] args = new String[] { "-x", "path1:path2", "file1", "file2" };
CommandLineParser parser = new PosixParser();
CommandLine cmdLine = null;
try {
cmdLine = parser.parse(opts, args);
} catch (ParseException ex) {
System.out.println("Syntax error: " + ex.getMessage());
return;
}
if (cmdLine.hasOption('x')) {
for (String path : cmdLine.getOptionValues('x'))
System.out.println("path: " + path);
}
for (Object file : cmdLine.getArgList()) {
System.out.println("file: " + file);
}
Surprisingly this doesn't function as expected. This is the output I get:
path: path1
path: path2
path: file1
path: file2
Not only the two '-x' option values ('path1', 'path2') but also the file
arguments are returned when the getOptionValues('x') function is called. No
matter which parser class I use (BasicParser, GnuParser or PosixParser), the
result is always the same.
What am I doing wrong?
Adalbert.
