You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by John Keyes <jb...@mac.com> on 2003/05/19 23:56:46 UTC
[CLI] cries out for stability ...
Well I've created a branch for the next version (I named the it
cli_1_x, what the hell was I on?) and commited the code. It
seemd the tar.gz I advertised was wrong as well (apologies
all around), well anyway lets hope I can build the momentum
up now and get some stability back...
I'll be posting updates to http://www.integralsource.com (I might
implement an RSS feed soon) so keep your eyes peeled.
-John K
- - - - - - - - - - - - - - - - - - - - - - -
Jakarta Commons CLI
http://jakarta.apache.org/commons/cli
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] cries out for stability ...
Posted by John Keyes <jb...@mac.com>.
Hi Rob,
I've taken on board your comments and have started doing some of the
work required. I am working sequentially, you can keep up with what
is going on at http://www.integralsource.com, I'll be posting daily
updates on what I've been doing (or just check the CVS mails).
-John K
On Tuesday, May 20, 2003, at 12:26 Europe/Dublin, Rob Oxspring wrote:
> Hiya, I was holding off comments until something appeared in CVS since
> its easier to tell which versions we are talking about then,
> and patches / commits become a possibility. I haven't actually used
> it yet but here's my initial comments after a perusal of the
> current code and a little play with the .tgz copy the other day:
>
> Builder methods - There was some talk of changing the isRequired()
> method to avoid JavaBean conflicts in peoples heads, I still
> favour the withRequired(boolean) names as being totally consistent
> with the rest of the builder methods. Actually I'd prefer to go
> the full distance and have withName(String), withLongName(String) and
> just one create() method but I suspect the crowd prefer the
> shorter syntax.
>
> OptionGroup implementations have a mandatory attribute which
> presumably mean the same as the required attribute of Option. I think
> these should be renamed to be the same. Seems odd that the attribute
> has been dropped from the interface too but I haven't
> investigated the use of inclusive vs. exclusive OptionGroups yet.
>
> Thinking forward to HelpFormatter I was wondering whether life might
> be easier if OptionGroups were able to have a name. I'm
> thinking that help showing:
>
> Input options:
> -f file
> -url url
>
> Would be a little prettier and more useful than:
>
> -f | -url
> -f file
> -url url
>
> Arguments have a size attribute currently, I'm wondering whether more
> flexibility might be afforded by the use of a minimum and
> maximum rather than a single size. This way we can automate errors
> saying "source needs at least 1 argument" taking some sort of
> copy command as an example. Equal minimum and maximum would indicate
> a fixed size as size does today.
>
> Adding more than one AnonymousArgument seems to be an error but it
> looks like Options just takes the last one supplied. Long term
> it seems to me that a list of anonymous arguments of a fixed size
> should be perfectly acceptable, and that its only multiple
> anonymous arguments of undetermined size that should cause an error.
> The current solution of ignoring some of the arguments is
> surely wrong though.
>
> AnonymousArgument currently throws UnsupportedOperationException for
> getDescription() - does this mean that no explanation can be
> automated in HelpFormatter later?
>
> JavaProperty handling is hardwired into CommandLineParser - my gut
> tells me that this should be optional but I could be swayed.
>
> Presumably a setPosix(boolean) method is waiting to be added to
> CommandLineParser too? looks like this is just a compile-time choice
> at the moment.
>
> Finally, am I right in thinking that we don't support the "jar cvf
> file.jar" (i.e. compressed options with no preceding '-') or the
> "svn status ./trunk" style of options / "subcommands"? Not a biggie
> but it'd be nice to support them if we can think our way through
> the problem - especially if we can support the command aliases
> "status"=="stat"=="st" too.
>
>
> All IMHO of course! The general impression is that it seems much
> cleaner and tidier, if lacking a few comments.
>
> Rob
>
> ----- Original Message -----
> From: "John Keyes" <jb...@mac.com>
> To: "commons-dev" <co...@jakarta.apache.org>
> Sent: Monday, May 19, 2003 10:56 PM
> Subject: [CLI] cries out for stability ...
>
>
>> Well I've created a branch for the next version (I named the it
>> cli_1_x, what the hell was I on?) and commited the code. It
>> seemd the tar.gz I advertised was wrong as well (apologies
>> all around), well anyway lets hope I can build the momentum
>> up now and get some stability back...
>>
>> I'll be posting updates to http://www.integralsource.com (I might
>> implement an RSS feed soon) so keep your eyes peeled.
>>
>> -John K
>> - - - - - - - - - - - - - - - - - - - - - - -
>> Jakarta Commons CLI
>> http://jakarta.apache.org/commons/cli
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
- - - - - - - - - - - - - - - - - - - - - - -
Jakarta Commons CLI
http://jakarta.apache.org/commons/cli
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] cries out for stability ...
Posted by Rob Oxspring <ro...@imapmail.org>.
Hiya, I was holding off comments until something appeared in CVS since its easier to tell which versions we are talking about then,
and patches / commits become a possibility. I haven't actually used it yet but here's my initial comments after a perusal of the
current code and a little play with the .tgz copy the other day:
Builder methods - There was some talk of changing the isRequired() method to avoid JavaBean conflicts in peoples heads, I still
favour the withRequired(boolean) names as being totally consistent with the rest of the builder methods. Actually I'd prefer to go
the full distance and have withName(String), withLongName(String) and just one create() method but I suspect the crowd prefer the
shorter syntax.
OptionGroup implementations have a mandatory attribute which presumably mean the same as the required attribute of Option. I think
these should be renamed to be the same. Seems odd that the attribute has been dropped from the interface too but I haven't
investigated the use of inclusive vs. exclusive OptionGroups yet.
Thinking forward to HelpFormatter I was wondering whether life might be easier if OptionGroups were able to have a name. I'm
thinking that help showing:
Input options:
-f file
-url url
Would be a little prettier and more useful than:
-f | -url
-f file
-url url
Arguments have a size attribute currently, I'm wondering whether more flexibility might be afforded by the use of a minimum and
maximum rather than a single size. This way we can automate errors saying "source needs at least 1 argument" taking some sort of
copy command as an example. Equal minimum and maximum would indicate a fixed size as size does today.
Adding more than one AnonymousArgument seems to be an error but it looks like Options just takes the last one supplied. Long term
it seems to me that a list of anonymous arguments of a fixed size should be perfectly acceptable, and that its only multiple
anonymous arguments of undetermined size that should cause an error. The current solution of ignoring some of the arguments is
surely wrong though.
AnonymousArgument currently throws UnsupportedOperationException for getDescription() - does this mean that no explanation can be
automated in HelpFormatter later?
JavaProperty handling is hardwired into CommandLineParser - my gut tells me that this should be optional but I could be swayed.
Presumably a setPosix(boolean) method is waiting to be added to CommandLineParser too? looks like this is just a compile-time choice
at the moment.
Finally, am I right in thinking that we don't support the "jar cvf file.jar" (i.e. compressed options with no preceding '-') or the
"svn status ./trunk" style of options / "subcommands"? Not a biggie but it'd be nice to support them if we can think our way through
the problem - especially if we can support the command aliases "status"=="stat"=="st" too.
All IMHO of course! The general impression is that it seems much cleaner and tidier, if lacking a few comments.
Rob
----- Original Message -----
From: "John Keyes" <jb...@mac.com>
To: "commons-dev" <co...@jakarta.apache.org>
Sent: Monday, May 19, 2003 10:56 PM
Subject: [CLI] cries out for stability ...
> Well I've created a branch for the next version (I named the it
> cli_1_x, what the hell was I on?) and commited the code. It
> seemd the tar.gz I advertised was wrong as well (apologies
> all around), well anyway lets hope I can build the momentum
> up now and get some stability back...
>
> I'll be posting updates to http://www.integralsource.com (I might
> implement an RSS feed soon) so keep your eyes peeled.
>
> -John K
> - - - - - - - - - - - - - - - - - - - - - - -
> Jakarta Commons CLI
> http://jakarta.apache.org/commons/cli
>
>
> ---------------------------------------------------------------------
> 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