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/11/01 00:40:48 UTC
Re: [CLI] 2.x Tasks
We definitely need to add these two tasks as well:
. mandatory groups
. child Options
-John K
On 23 Oct 2003, at 11:31, Rob Oxspring wrote:
> It should do - certainly the things in yesterday's are all now in
> bugzilla
> (or fixed in the sandbox).
>
> It leaves us with 32 bugs but not all will be strictly 2.0 tasks.
> Some are
> detail bugs that are probably specific to cli1 (not to say that cli2
> won't
> have bugs) and some should be deferred until 2.1 or later.
>
> Rob
>
> ----- Original Message -----
> From: "John Keyes" <jb...@mac.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Thursday, October 23, 2003 11:03 AM
> Subject: Re: [CLI] 2.x Tasks
>
>
>> Great stuff Rob. Does this mean all remaining tasks
>> can be found in Bugzilla?
>>
>> -John K
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [CLI] 2.x Tasks
Posted by Rob Oxspring <ro...@imapmail.org>.
----- Original Message -----
From: "John Keyes" <jb...@mac.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, November 02, 2003 9:04 PM
Subject: Re: [CLI] 2.x Tasks
> >>>> Here's a toy example:
> >>>>
> >>>> -topleft -x 10 -y 10 -bottomright -x 20 -y 20
> >>>>
> >>>> where the group is the x and y Arguments.
> >>>>
> >>>> Does that make any sense?
> >>>
> >>> Annoyingly, yes. :)
> >>>
> >>> So the problem is that when querying a CommandLine configured by the
> >>> above
> >>> we have no way of which -x and -y go with which -topleft and
> >>> -bottomright.
> >
> > This is the problem you're trying to solve right?
> Yeap.
>
> >>> The only way to achive this query is to use the path of the options
> >>> along
> >>> the lines of:
> >>> xValue = commandLine.getValue("-topleft","-x");
> >>> I don't see any reason for limiting the path length so I guess the
> >>> api needs
> >>> to allow for an array / list / iterator or similar. Of course this
> >>> means
> >>> that the current option->values map is no longer up to the job, and
> >>> some
> >>> path->values is going to be needed. I'm beginning to think that we
> >>> need an
> >>> object to represent a option's path to key from.
> >>
> >> Well my idea was to have an inclusive group. So we could have:
> >>
> >> Group coords = gBuilder.withOption(x)
> >> .withOption(y)
> >> .withType(Group.INCLUSIVE);
> >>
> >> Option topleft = oBuilder.withShortName("topleft")
> >> .withOption(coords)
> >> .create();
> >>
> >> Option bottomright = oBuilder.withShortName("bottomright")
> >> .withOption(coords)
> >> .create();
> >>
> >> Then the process logic in GroupImpl will check that all
> >> of the options in that group are present, if not throw
> >> a MissingOptionException.
> >>
> >> How does that sound? This sounds like a much simpler
> >> solution rather than the Path proposal. If I am
> >> missing something let me know.
> >
> > That should work fine for parsing and validating but there is still the
> > problem at the interrogation stage. When the querying code then does a
> >
> > List xValues = cl.getValues(x);
> >
> > It'll be faced with the values of both the topleft x and the
> > bottomright x,
> > in an order dependant on the command line arguments supplied. This
> > would
> > work but it seems to me that we should do more.
> >
> > That make sense?
>
> I knew I was missing something :-) The Preferences API uses '/' as the
> separator and so does XPath so I think we should go with that? If
> max > 1 we should use array notation with indicies beginning at 0?
>
> So we could use:
> getValue("/topleft/x"); // return a List of size 1
>
> If the max = 2 we could use:
> getValue("/topleft/x[1]"); // return a List of size 1
> getValue("/topleft/x"); // return a List of size 2
So use a String instead of some new fangled Path object? Seems reasonable
enough, although the [1] style indexing might lead to other xpath style
expectation. Not thought about that too much though.
>
> Should we drop the support for the trigger? So regardless of the
> trigger could we retrieve values without it:
>
> getValue("topleft");
I kind of like using the triggers as they add lots of flexibility but the
number of method overloadings for convenience is pretty high.
>
> internally if the string does not contain any '/' we search for
> "/topleft". This will give us a single means of retrieving the
> values.
>
> (more further down)
>
> >>> For this to work we need to arrange for the pathToValues map to be
> >>> populated. One option would make all option instances aware of
> >>> their parent
> >>> and so make it easy to identify the path, unfortunately this means
> >>> that the
> >>> same option/group can't appear in multiple places within the
> >>> structure which
> >>> is a useful feature IMHO. Perhaps the easiest solution is to make
> >>> all the
> >>> process(..) methods take an additional Path argument. This way, as
> >>> control
> >>> is delegated to other arguments / children / group members, the
> >>> appropriate
> >>> Path can be constructed based on the one passed in and can be passed
> >>> to the
> >>> delagate's process method.
> >>>
> >>> Begin able to deal with option paths is also relevant to processing
> >>> Properties / Prefs / xml / etc into a CommandLine. Given a property
> >>> "topleft.x" we need to first verify that the path topleft>x is valid
> >>> and
> >>> then associate any values / switches in the CommandLine. I guess the
> >>> easiest thing here would be to add a method in Option along the lines
> >>> of:
> >>> /** Finds the option associated with the path from this option or
> >>> * null if the path is invalid
> >>> */
> >>> Option find(Path path);
>
> Yeah sounds good.
>
> >>> This is fine if the we can use the properties to drive the options
> >>> but this
> >>> might not always be the best way forward but adding another method
> >>> to Option
> >>> to find the valid paths should allow options to drive the prefs too.
> >>> /** Finds all the valid option paths rooted at this option */
> >>> Set findPaths();
>
> I get the feeling I'm being dozy again. I think this would be a good
> method
> for testing but can you explain why we would need this method defined on
> the API?
It's probably not necessary. The thinking was that when the preferences
have loads of values (thinking windows Registry as an example) it would be
impractical to iterate over all them and say "does this refer to an
option?". Instead the findPaths() method would allow them to query the root
option and use those values to search the preferences.
Cheers,
Rob
>
> Thanks,
> -John K
>
>
> ---------------------------------------------------------------------
> 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
Re: [CLI] 2.x Tasks
Posted by John Keyes <jb...@mac.com>.
>>>> Here's a toy example:
>>>>
>>>> -topleft -x 10 -y 10 -bottomright -x 20 -y 20
>>>>
>>>> where the group is the x and y Arguments.
>>>>
>>>> Does that make any sense?
>>>
>>> Annoyingly, yes. :)
>>>
>>> So the problem is that when querying a CommandLine configured by the
>>> above
>>> we have no way of which -x and -y go with which -topleft and
>>> -bottomright.
>
> This is the problem you're trying to solve right?
Yeap.
>>> The only way to achive this query is to use the path of the options
>>> along
>>> the lines of:
>>> xValue = commandLine.getValue("-topleft","-x");
>>> I don't see any reason for limiting the path length so I guess the
>>> api needs
>>> to allow for an array / list / iterator or similar. Of course this
>>> means
>>> that the current option->values map is no longer up to the job, and
>>> some
>>> path->values is going to be needed. I'm beginning to think that we
>>> need an
>>> object to represent a option's path to key from.
>>
>> Well my idea was to have an inclusive group. So we could have:
>>
>> Group coords = gBuilder.withOption(x)
>> .withOption(y)
>> .withType(Group.INCLUSIVE);
>>
>> Option topleft = oBuilder.withShortName("topleft")
>> .withOption(coords)
>> .create();
>>
>> Option bottomright = oBuilder.withShortName("bottomright")
>> .withOption(coords)
>> .create();
>>
>> Then the process logic in GroupImpl will check that all
>> of the options in that group are present, if not throw
>> a MissingOptionException.
>>
>> How does that sound? This sounds like a much simpler
>> solution rather than the Path proposal. If I am
>> missing something let me know.
>
> That should work fine for parsing and validating but there is still the
> problem at the interrogation stage. When the querying code then does a
>
> List xValues = cl.getValues(x);
>
> It'll be faced with the values of both the topleft x and the
> bottomright x,
> in an order dependant on the command line arguments supplied. This
> would
> work but it seems to me that we should do more.
>
> That make sense?
I knew I was missing something :-) The Preferences API uses '/' as the
separator and so does XPath so I think we should go with that? If
max > 1 we should use array notation with indicies beginning at 0?
So we could use:
getValue("/topleft/x"); // return a List of size 1
If the max = 2 we could use:
getValue("/topleft/x[1]"); // return a List of size 1
getValue("/topleft/x"); // return a List of size 2
Should we drop the support for the trigger? So regardless of the
trigger could we retrieve values without it:
getValue("topleft");
internally if the string does not contain any '/' we search for
"/topleft". This will give us a single means of retrieving the
values.
(more further down)
>>> For this to work we need to arrange for the pathToValues map to be
>>> populated. One option would make all option instances aware of
>>> their parent
>>> and so make it easy to identify the path, unfortunately this means
>>> that the
>>> same option/group can't appear in multiple places within the
>>> structure which
>>> is a useful feature IMHO. Perhaps the easiest solution is to make
>>> all the
>>> process(..) methods take an additional Path argument. This way, as
>>> control
>>> is delegated to other arguments / children / group members, the
>>> appropriate
>>> Path can be constructed based on the one passed in and can be passed
>>> to the
>>> delagate's process method.
>>>
>>> Begin able to deal with option paths is also relevant to processing
>>> Properties / Prefs / xml / etc into a CommandLine. Given a property
>>> "topleft.x" we need to first verify that the path topleft>x is valid
>>> and
>>> then associate any values / switches in the CommandLine. I guess the
>>> easiest thing here would be to add a method in Option along the lines
>>> of:
>>> /** Finds the option associated with the path from this option or
>>> * null if the path is invalid
>>> */
>>> Option find(Path path);
Yeah sounds good.
>>> This is fine if the we can use the properties to drive the options
>>> but this
>>> might not always be the best way forward but adding another method
>>> to Option
>>> to find the valid paths should allow options to drive the prefs too.
>>> /** Finds all the valid option paths rooted at this option */
>>> Set findPaths();
I get the feeling I'm being dozy again. I think this would be a good
method
for testing but can you explain why we would need this method defined on
the API?
Thanks,
-John K
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] 2.x Tasks
Posted by Rob Oxspring <ro...@imapmail.org>.
----- Original Message -----
From: "John Keyes" <jb...@mac.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, November 02, 2003 7:35 PM
Subject: Re: [CLI] 2.x Tasks
> >> Here's a toy example:
> >>
> >> -topleft -x 10 -y 10 -bottomright -x 20 -y 20
> >>
> >> where the group is the x and y Arguments.
> >>
> >> Does that make any sense?
> >
> > Annoyingly, yes. :)
> >
> > So the problem is that when querying a CommandLine configured by the
> > above
> > we have no way of which -x and -y go with which -topleft and
> > -bottomright.
This is the problem you're trying to solve right?
> >
> > The only way to achive this query is to use the path of the options
> > along
> > the lines of:
> > xValue = commandLine.getValue("-topleft","-x");
> > I don't see any reason for limiting the path length so I guess the api
> > needs
> > to allow for an array / list / iterator or similar. Of course this
> > means
> > that the current option->values map is no longer up to the job, and
> > some
> > path->values is going to be needed. I'm beginning to think that we
> > need an
> > object to represent a option's path to key from.
>
> Well my idea was to have an inclusive group. So we could have:
>
> Group coords = gBuilder.withOption(x)
> .withOption(y)
> .withType(Group.INCLUSIVE);
>
> Option topleft = oBuilder.withShortName("topleft")
> .withOption(coords)
> .create();
>
> Option bottomright = oBuilder.withShortName("bottomright")
> .withOption(coords)
> .create();
>
> Then the process logic in GroupImpl will check that all
> of the options in that group are present, if not throw
> a MissingOptionException.
>
> How does that sound? This sounds like a much simpler
> solution rather than the Path proposal. If I am
> missing something let me know.
That should work fine for parsing and validating but there is still the
problem at the interrogation stage. When the querying code then does a
List xValues = cl.getValues(x);
It'll be faced with the values of both the topleft x and the bottomright x,
in an order dependant on the command line arguments supplied. This would
work but it seems to me that we should do more.
That make sense?
Rob
>
> Cheers,
> -John K
>
> > For this to work we need to arrange for the pathToValues map to be
> > populated. One option would make all option instances aware of their
> > parent
> > and so make it easy to identify the path, unfortunately this means
> > that the
> > same option/group can't appear in multiple places within the structure
> > which
> > is a useful feature IMHO. Perhaps the easiest solution is to make all
> > the
> > process(..) methods take an additional Path argument. This way, as
> > control
> > is delegated to other arguments / children / group members, the
> > appropriate
> > Path can be constructed based on the one passed in and can be passed
> > to the
> > delagate's process method.
> >
> > Begin able to deal with option paths is also relevant to processing
> > Properties / Prefs / xml / etc into a CommandLine. Given a property
> > "topleft.x" we need to first verify that the path topleft>x is valid
> > and
> > then associate any values / switches in the CommandLine. I guess the
> > easiest thing here would be to add a method in Option along the lines
> > of:
> > /** Finds the option associated with the path from this option or
> > null
> > if the path is invalid */
> > Option find(Path path);
> > This is fine if the we can use the properties to drive the options but
> > this
> > might not always be the best way forward but adding another method to
> > Option
> > to find the valid paths should allow options to drive the prefs too.
> > /** Finds all the valid option paths rooted at this option */
> > Set findPaths();
> >
> > Thoughts ?
> >
> > Rob
> >
> >
> >>
> >> -John K
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [CLI] 2.x Tasks
Posted by John Keyes <jb...@mac.com>.
>> Here's a toy example:
>>
>> -topleft -x 10 -y 10 -bottomright -x 20 -y 20
>>
>> where the group is the x and y Arguments.
>>
>> Does that make any sense?
>
> Annoyingly, yes. :)
>
> So the problem is that when querying a CommandLine configured by the
> above
> we have no way of which -x and -y go with which -topleft and
> -bottomright.
>
> The only way to achive this query is to use the path of the options
> along
> the lines of:
> xValue = commandLine.getValue("-topleft","-x");
> I don't see any reason for limiting the path length so I guess the api
> needs
> to allow for an array / list / iterator or similar. Of course this
> means
> that the current option->values map is no longer up to the job, and
> some
> path->values is going to be needed. I'm beginning to think that we
> need an
> object to represent a option's path to key from.
Well my idea was to have an inclusive group. So we could have:
Group coords = gBuilder.withOption(x)
.withOption(y)
.withType(Group.INCLUSIVE);
Option topleft = oBuilder.withShortName("topleft")
.withOption(coords)
.create();
Option bottomright = oBuilder.withShortName("bottomright")
.withOption(coords)
.create();
Then the process logic in GroupImpl will check that all
of the options in that group are present, if not throw
a MissingOptionException.
How does that sound? This sounds like a much simpler
solution rather than the Path proposal. If I am
missing something let me know.
Cheers,
-John K
> For this to work we need to arrange for the pathToValues map to be
> populated. One option would make all option instances aware of their
> parent
> and so make it easy to identify the path, unfortunately this means
> that the
> same option/group can't appear in multiple places within the structure
> which
> is a useful feature IMHO. Perhaps the easiest solution is to make all
> the
> process(..) methods take an additional Path argument. This way, as
> control
> is delegated to other arguments / children / group members, the
> appropriate
> Path can be constructed based on the one passed in and can be passed
> to the
> delagate's process method.
>
> Begin able to deal with option paths is also relevant to processing
> Properties / Prefs / xml / etc into a CommandLine. Given a property
> "topleft.x" we need to first verify that the path topleft>x is valid
> and
> then associate any values / switches in the CommandLine. I guess the
> easiest thing here would be to add a method in Option along the lines
> of:
> /** Finds the option associated with the path from this option or
> null
> if the path is invalid */
> Option find(Path path);
> This is fine if the we can use the properties to drive the options but
> this
> might not always be the best way forward but adding another method to
> Option
> to find the valid paths should allow options to drive the prefs too.
> /** Finds all the valid option paths rooted at this option */
> Set findPaths();
>
> Thoughts ?
>
> Rob
>
>
>>
>> -John K
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] 2.x Tasks
Posted by Rob Oxspring <ro...@imapmail.org>.
----- Original Message -----
From: "John Keyes" <jb...@mac.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, November 02, 2003 1:15 AM
Subject: Re: [CLI] 2.x Tasks
> Here's a toy example:
>
> -topleft -x 10 -y 10 -bottomright -x 20 -y 20
>
> where the group is the x and y Arguments.
>
> Does that make any sense?
Annoyingly, yes. :)
So the problem is that when querying a CommandLine configured by the above
we have no way of which -x and -y go with which -topleft and -bottomright.
The only way to achive this query is to use the path of the options along
the lines of:
xValue = commandLine.getValue("-topleft","-x");
I don't see any reason for limiting the path length so I guess the api needs
to allow for an array / list / iterator or similar. Of course this means
that the current option->values map is no longer up to the job, and some
path->values is going to be needed. I'm beginning to think that we need an
object to represent a option's path to key from.
For this to work we need to arrange for the pathToValues map to be
populated. One option would make all option instances aware of their parent
and so make it easy to identify the path, unfortunately this means that the
same option/group can't appear in multiple places within the structure which
is a useful feature IMHO. Perhaps the easiest solution is to make all the
process(..) methods take an additional Path argument. This way, as control
is delegated to other arguments / children / group members, the appropriate
Path can be constructed based on the one passed in and can be passed to the
delagate's process method.
Begin able to deal with option paths is also relevant to processing
Properties / Prefs / xml / etc into a CommandLine. Given a property
"topleft.x" we need to first verify that the path topleft>x is valid and
then associate any values / switches in the CommandLine. I guess the
easiest thing here would be to add a method in Option along the lines of:
/** Finds the option associated with the path from this option or null
if the path is invalid */
Option find(Path path);
This is fine if the we can use the properties to drive the options but this
might not always be the best way forward but adding another method to Option
to find the valid paths should allow options to drive the prefs too.
/** Finds all the valid option paths rooted at this option */
Set findPaths();
Thoughts ?
Rob
>
> -John K
>
>
> ---------------------------------------------------------------------
> 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
Re: [CLI] 2.x Tasks
Posted by John Keyes <jb...@mac.com>.
>> 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.
>
> There's currently no problem with assigning the same group as children
> to more than one parent but I'm not 100% sure this is tackling the
> same problem. Any chance of a toy example of inclusive groups to make
> sure we're on the same wavelength?
Oh sure, there's no problem with doing it currently but only
for exclusive options.
Here's a toy example:
-topleft -x 10 -y 10 -bottomright -x 20 -y 20
where the group is the x and y Arguments.
Does that make any sense?
-John K
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] 2.x Tasks
Posted by Rob Oxspring <ro...@imapmail.org>.
John Keyes wrote:
> 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.
There's currently no problem with assigning the same group as children
to more than one parent but I'm not 100% sure this is tackling the same
problem. Any chance of a toy example of inclusive groups to make sure
we're on the same wavelength?
Cheers,
Rob
>
> -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: 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] 2.x Tasks
Posted by John Keyes <jb...@mac.com>.
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: 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
Re: Using Jira (was RE: [CLI] 2.x Tasks)
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 2 Nov 2003, Rob Oxspring wrote:
> I'm happy to switch to jira as and when, although I've used it before
> for reporting the grand total of 1 bug but I expect it'll be straight
> forward. Anything's going to be a bit nicer than bugzilla!
Just to throw in my tuppence,
I've been using JIRA at work and at http://www.osjava.org. Apart from a
worry that the sheer number of projects will make the default front page
unworkable, JIRA is a joy to use.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Using Jira (was RE: [CLI] 2.x Tasks)
Posted by Rob Oxspring <ro...@imapmail.org>.
John Keyes wrote:
>
>>> 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.
>>
>>
>> Not yet, please. We're still tuning the installation, and will
>> certainly
>> blow away the current database at least once more before declaring it
>> open.
>> We'll probably do a bugzilla import once before blowing away the
>> current db.
>
>
> Sure thing. Just wanted to see what other cli heads thought.
I'm happy to switch to jira as and when, although I've used it before
for reporting the grand total of 1 bug but I expect it'll be straight
forward. Anything's going to be a bit nicer than bugzilla!
Rob
>
> Thanks,
> -John K
>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: Using Jira (was RE: [CLI] 2.x Tasks)
Posted by John Keyes <jb...@mac.com>.
>> 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.
>
> Not yet, please. We're still tuning the installation, and will
> certainly
> blow away the current database at least once more before declaring it
> open.
> We'll probably do a bugzilla import once before blowing away the
> current db.
Sure thing. Just wanted to see what other cli heads thought.
Thanks,
-John K
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Using Jira (was RE: [CLI] 2.x Tasks)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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.
Not yet, please. We're still tuning the installation, and will certainly
blow away the current database at least once more before declaring it open.
We'll probably do a bugzilla import once before blowing away the current db.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] 2.x Tasks
Posted by John Keyes <jb...@mac.com>.
>> . 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] 2.x Tasks
Posted by Rob Oxspring <ro...@imapmail.org>.
----- Original Message -----
From: "John Keyes" <jb...@mac.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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,
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org