You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rob Oxspring <ro...@imapmail.org> on 2005/04/06 21:09:22 UTC
[VOTE][CLI] 2.0 Release at last?
Hi all,
CLI2 has been pretty stable and it hasn't had any code changes since the
end of Feb. Its a ground up rewrite of 1.0 aiming to be more flexible
and maintainable. The only remaining bugs are 1.0 issues that don't
apply / are fixed in 2.0, I plan to mark them resolved once 2.0 is
available. So how about releasing it? I tried a while back but got
distracted and had other work todo but I promise I'll see it through
this time :)
The proposed release is available at:
http://people.apache.org/~roxspring/cli/
Here's my +1!
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE][CLI] 2.0 Release at last?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
looks ok to me
+1
- robert
On Thu, 2005-04-07 at 11:14 +0100, Rob Oxspring wrote:
> Thanks for that, fixed now.
>
> Rob
>
> robert burrell donkin wrote:
> > i think that the NOTICE file may be missing
> >
> > - robert
> >
> > On Wed, 2005-04-06 at 20:09 +0100, Rob Oxspring wrote:
> >
> >>Hi all,
> >>
> >>CLI2 has been pretty stable and it hasn't had any code changes since the
> >>end of Feb. Its a ground up rewrite of 1.0 aiming to be more flexible
> >>and maintainable. The only remaining bugs are 1.0 issues that don't
> >>apply / are fixed in 2.0, I plan to mark them resolved once 2.0 is
> >>available. So how about releasing it? I tried a while back but got
> >>distracted and had other work todo but I promise I'll see it through
> >>this time :)
> >>
> >>The proposed release is available at:
> >>http://people.apache.org/~roxspring/cli/
> >>
> >>Here's my +1!
> >>
> >>Rob
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE][CLI] 2.0 Release at last?
Posted by Rob Oxspring <ro...@imapmail.org>.
Thanks for that, fixed now.
Rob
robert burrell donkin wrote:
> i think that the NOTICE file may be missing
>
> - robert
>
> On Wed, 2005-04-06 at 20:09 +0100, Rob Oxspring wrote:
>
>>Hi all,
>>
>>CLI2 has been pretty stable and it hasn't had any code changes since the
>>end of Feb. Its a ground up rewrite of 1.0 aiming to be more flexible
>>and maintainable. The only remaining bugs are 1.0 issues that don't
>>apply / are fixed in 2.0, I plan to mark them resolved once 2.0 is
>>available. So how about releasing it? I tried a while back but got
>>distracted and had other work todo but I promise I'll see it through
>>this time :)
>>
>>The proposed release is available at:
>>http://people.apache.org/~roxspring/cli/
>>
>>Here's my +1!
>>
>>Rob
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE][CLI] 2.0 Release at last?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
i think that the NOTICE file may be missing
- robert
On Wed, 2005-04-06 at 20:09 +0100, Rob Oxspring wrote:
> Hi all,
>
> CLI2 has been pretty stable and it hasn't had any code changes since the
> end of Feb. Its a ground up rewrite of 1.0 aiming to be more flexible
> and maintainable. The only remaining bugs are 1.0 issues that don't
> apply / are fixed in 2.0, I plan to mark them resolved once 2.0 is
> available. So how about releasing it? I tried a while back but got
> distracted and had other work todo but I promise I'll see it through
> this time :)
>
> The proposed release is available at:
> http://people.apache.org/~roxspring/cli/
>
> Here's my +1!
>
> Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE][CLI] 2.0 Release at last?
Posted by Torsten Curdt <tc...@apache.org>.
Rob Oxspring wrote:
> Hi all,
>
> CLI2 has been pretty stable and it hasn't had any code changes since the
> end of Feb. Its a ground up rewrite of 1.0 aiming to be more flexible
> and maintainable. The only remaining bugs are 1.0 issues that don't
> apply / are fixed in 2.0, I plan to mark them resolved once 2.0 is
> available. So how about releasing it? I tried a while back but got
> distracted and had other work todo but I promise I'll see it through
> this time :)
>
> The proposed release is available at:
> http://people.apache.org/~roxspring/cli/
>
> Here's my +1!
At least a non-binding applause from me ;)
...let me know if I can be of any help
cheers
--
Torsten
Re: [CLI2] quoting
Posted by Torsten Curdt <tc...@apache.org>.
> The problem here is that "-c" looks like an option. The simplest ways
Yes, and reason why is because the shell
that executes the vm will remove the "
So what I would get is
command --option1 "-c -P" --option2
[--option1]
[-c -P]
[--option2]
Now we *could* say that since there are
obviously two options in one string of
the array it must have been surrounded
by a " ...which means it was not meant
to be option but an argument.
Not sure if that's always valid. But on
the first glance this makes sense to me.
WDYT?
> around it are to use the -- "consume remaining" to capture the things
> that look like short options:
> command --options1 -- -c -P --option2
> But you do run the risk of -c, -P and -option2 being consumed as
> arguments to --option1.
That doesn't work for me.
I cannot really easily change the
way commandline is looking like.
(needs to be compatible to a legacy app)
> Alternatively you could set up your
> DefaultOptionBuilder with something other than "-" for the short option
> prefix - if you're not using short options at all then reusing "--"
> should skirt around the issue pretty well.
Hm... that's an idea :)
cheers
--
Torsten
Re: [CLI2] quoting
Posted by Rob Oxspring <ro...@imapmail.org>.
Torsten Curdt wrote:
> Torsten Curdt wrote:
>
>>>The proposed release is available at:
>>>http://people.apache.org/~roxspring/cli/
>
>
> ...another thing:
>
> command --option1 "-c -P" --option2
>
> currently CLI1 and CLI2 is treating this
> as if it were
>
> command --option1 -c -P --option2
>
> which is not what I want. For me "-c -P" is
> a string which is the argument of option1.
>
> Bug or desired behaviour?
The problem here is that "-c" looks like an option. The simplest ways
around it are to use the -- "consume remaining" to capture the things
that look like short options:
command --options1 -- -c -P --option2
But you do run the risk of -c, -P and -option2 being consumed as
arguments to --option1. Alternatively you could set up your
DefaultOptionBuilder with something other than "-" for the short option
prefix - if you're not using short options at all then reusing "--"
should skirt around the issue pretty well.
Hope that helps,
Rob
>
> cheers
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[CLI2] quoting
Posted by Torsten Curdt <tc...@apache.org>.
Torsten Curdt wrote:
>>The proposed release is available at:
>>http://people.apache.org/~roxspring/cli/
...another thing:
command --option1 "-c -P" --option2
currently CLI1 and CLI2 is treating this
as if it were
command --option1 -c -P --option2
which is not what I want. For me "-c -P" is
a string which is the argument of option1.
Bug or desired behaviour?
cheers
--
Torsten
Re: [CLI2] getting values
Posted by Rob Oxspring <ro...@imapmail.org>.
Torsten Curdt wrote:
>>The proposed release is available at:
>>http://people.apache.org/~roxspring/cli/
>
>
> Rob,
>
> I've been playing with the CLI2 stuff now.
> Great stuff! ...but something I found confusing
>
> Let's say I create my option like this:
>
> final Set set = new HashSet();
> set.add("a1");
> set.add("a2");
> set.add("a3");
>
> final Option oOption1 =
> oBuilder
> .withDescription(Messages.getString("Main.cli.option." +
> CommandlineOption.ALGORITHM))
> .withRequired(true)
> .withArgument(
> aBuilder
> .withMinimum(1)
> .withMaximum(1)
> .withValidator(new EnumValidator(set))
> .create())
> .withLongName(CommandlineOption.ALGORITHM)
> .create();
>
> And then later want to get the value from it:
>
> final String v =
> (String) cmd.getValue("--" + CommandlineOption.ALGORITHM);
>
>
> I find adding "--" quite inconvenient. Why here this prefix?
The prefix is needed here because the getValue() method takes any string
as might be entered by the user. I understand that it can be a bit
confusing but I tend to see people using hard coded strings in their
application where asking for the values of "--algorithm" is quite
intuitive. Alternatively I tend to set up an Option instance as a constant:
Option ALGORITHM = ...
and later:
final String v = (String) cmd.getValue(ALGORITHM)
>
> Also I am wondering what you think about adding some
> getValuesAsXXX functions. Alway having an explicit cast
> is kind of annoying.
>
> Or am I missing something?
There was a plan a while back of adding a TypedCommandLine that would
wrap a CommandLine instance and provide such methods. I didn't get
around to it since there wasn't much demand.
Could be added pretty easily but I think we should push for a 2.0 now
and make the new methods available in a 2.1 so that the api can settle.
THoughts?
Rob
>
> cheers
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[CLI2] getting values
Posted by Torsten Curdt <tc...@apache.org>.
> The proposed release is available at:
> http://people.apache.org/~roxspring/cli/
Rob,
I've been playing with the CLI2 stuff now.
Great stuff! ...but something I found confusing
Let's say I create my option like this:
final Set set = new HashSet();
set.add("a1");
set.add("a2");
set.add("a3");
final Option oOption1 =
oBuilder
.withDescription(Messages.getString("Main.cli.option." +
CommandlineOption.ALGORITHM))
.withRequired(true)
.withArgument(
aBuilder
.withMinimum(1)
.withMaximum(1)
.withValidator(new EnumValidator(set))
.create())
.withLongName(CommandlineOption.ALGORITHM)
.create();
And then later want to get the value from it:
final String v =
(String) cmd.getValue("--" + CommandlineOption.ALGORITHM);
I find adding "--" quite inconvenient. Why here this prefix?
Also I am wondering what you think about adding some
getValuesAsXXX functions. Alway having an explicit cast
is kind of annoying.
Or am I missing something?
cheers
--
Torsten