Re: [CLI] 2.x Tasks

[John Keyes]

   . 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]