commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Keyes <>
Subject Re: [CLI] 2.x Tasks
Date Sat, 01 Nov 2003 14:43:57 GMT
>>    . 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.
Doh!  Of course.

>>    . 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 forgot Group extends Options.

> I'm quite happy to add the tasks but my head needs a bit more detail 
> to get round it at the moment.
No need, I've got my head around them now.

> 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?
Nice idea.  It will be important to have good documentation to show
how many of the new features in 2.x works.  This sounds like a good
example, we can include it in the distribution and also document it
as an extension example.  Whether this should be considered a core
feature or an extension feature is another question?  If we have
other extension examples maybe we should put this into a separate

> 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.

I'd like to see the code for this.  I was going to start work on the
properties/prefs/... task next.

> 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?

Yeah I saw this.  I think it is the correct approach.  Originally this
requirement came from some code in Avalon, this was a specific case 
each option was only one character.  This should be easy to wrap for the
cli package delegators as well.

Now that we have jira on nagoya should we move to use this instead of
Bugzilla?  No biggy, but it is much a nicer interface than bugzilla.

-John K

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

View raw message