commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <>
Subject Re: [CLI] 2.x Tasks
Date Sat, 01 Nov 2003 01:49:07 GMT

----- Original Message ----- 
From: "John Keyes" <>
To: "Jakarta Commons Developers List" <>
Sent: Friday, October 31, 2003 11:40 PM
Subject: Re: [CLI] 2.x Tasks

> We definitely need to add these two tasks as well:
>    . mandatory groups

I think this can be achieved using min/max with Groups but I might be
missing the point.  I'm not going to claim that this is well documented or
intuitive though so ideas welcome.

>    . child Options

Parent instances can have a "children" Group - doesn't this take care of
things?  Or do you want to have a single child?

I'm quite happy to add the tasks but my head needs a bit more detail to get
round it at the moment.

As for other tasks...

I've got code in the wings for a SourceDestArgument.  It was meant as a
worked example of extending the system but I'm wondering whether it might
just as well be included.  Basically it implements the logic of "cp"s
arguments - many sources + 1 destination, allowing the user to get around
the greedy parsing logic.  Thoughts? More code/explanation needed?

I've also got work in progress code to allow defaults to be taken from
another CommandLine instance.  The idea is that these can be daisy chained
and then other parsers can be written to deal with Properties, Prefs, xml?,
CommonsConfiguration?? etc.  Along with the parser logic, writing logic
could be added to arrive at property setting logic requested in one of the
bugs.  Does this sound like goodness?  I'll go into detail about the
thoughts re parsing and writing as I'm struggling to find the right api in
my head.

And while I'm here and awake (almost) - I added getId() to Option the other
day so that switching can be performed on options but the code makes no
attempt to ensure the id's don't clash or to automatically assign ids.  I
briefly had it using the (char) of any 1 character shortNames or an ever
increasing number otherwise but that just seemed to be trying too hard and
achieving too little and I figured I'd chuck responsibility to the user that
wants to use ids.  Which is this the right approach?

Anyway, just food for thought,


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message