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 Sun, 02 Nov 2003 00:33:22 GMT
Our current group support is limited to mutually
exclusive groups.  We need to support inclusive
groups also.  This will allow more than one option
to have the same child options.  Let me know if you
have any thoughts on it.

-John K

On 1 Nov 2003, at 14:43, John Keyes wrote:

>>>    . 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
> package?
>> 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 
> where
> 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:

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

View raw message