commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Keyes <j...@mac.com>
Subject Re: [CLI] 2.x Tasks
Date Thu, 23 Oct 2003 10:03:48 GMT
Great stuff Rob.  Does this mean all remaining tasks
can be found in Bugzilla?

-John K

On Thursday, Oct 23, 2003, at 10:31 Europe/Dublin, Rob Oxspring wrote:

> ----- Original Message -----
> From: "John Keyes" <jbjk@mac.com>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Wednesday, October 22, 2003 4:07 PM
> Subject: Re: [CLI] 2.x Tasks
>
>
>>>  ======== Minor Enhancements ========
>>>
>>> 1.1) Posix option parsing should be default
>>>
>>> Posix parsing should be preferred. I.e. -buildfile should be parsed  
>>> in
> the
>>> following order of preference
>>>
>>> -b uildfile
>>> -b -u -i -l -d -f -i -l -e.
>>> -buildfile
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=102008725729133&w=2
>>
>> +1
>
> Done, but discussion needed.
>
>>
>>> 1.2) Property options don't need '=' sign
>>>
>>> When parsing -D style property options the absense of '=' should
> indicate
>>> that the property be set with a value of "true".
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=102435665623207&w=2
>>
>> +1
>
> Done.
>
>>
>>> 1.3) Enum Argument Values
>>>
>>> Options should allow a list of possible values to validate against.
>>> Currently this is in StringValidator but would EnumValidator be  
>>> better
> name?
>>> StringArrayValidator is also a suggested name.
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=102750803811805&w=2
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=103951380212779&w=2
>>
>> +1 to EnumValidator
>
> Done.
>
>>
>>> 1.4) CommandLine Options should be ordered
>>>
>>> When processing the options in a CommandLine instance it is sometimes
>>> relevant to know what order they were set in.
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=103183663329683&w=2
>>
>> +1
>>
>>> 1.5) Ordering options in help
>>>
>>> When options are displayed in help it would be useful to use the  
>>> order
> the
>>> options were set in.
>>>
>>> Bug#: 20216
>
> Done
>
>>
>> This should be configurable by supplying a comparator.
>>
>>>  ======== Bigger Enhancements ========
>>>
>>> 2.1) Interrogation using switch statement
>>>
>>> It should be possible to interrogate options using a simple a switch  
>>> in
> a
>>> loop.  This requires a unique integer id for each option.
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=102763403105912&w=2
>>
>> +1 (got to keep the features that were available in the original)
>
> #24036
>
>>
>>> 2.2) Multiple Option Occurrences
>>>
>>> When the same option occurs multiple times this should be recorded in
> the
>>> CommandLine.  For example while -v might mean verbose, -v -v might  
>>> mean
> very
>>> verbose.
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=102820668701775&w=2
>>
>> I forgot about this.  Possibly a 2.x?
>
> #24037
>
>>
>>> 2.3) All arguments should have ConsumeRemaining behaviour
>>>
>>> ConsumeRemainingOption could be dropped in favour of the feature  
>>> being
> added
>>> to ArgumentImpl.  This would mean that the concept of "unprocessed"
> options
>>> could be removed and the values could still be validated and  
>>> associated
> with
>>> arguments.
>>
>> +1
>
> #24038
>
>>
>>> 2.3) Factored out help for common groups
>>>
>>> If the same group is used within several different options then the  
>>> help
>>> system should be able to display the information more consisely.   
>>> I.e.
> the
>>> common group is printed separately.
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=104452882903157&w=2
>>>
>>
>> 2.x I would say.
>
> #24039
>
>>
>>>  ======== Validators and Triggers ========
>>>
>>> 3.1) Per option Triggers
>>>
>>> When an option is processed some custom "trigger" (ala SQL) could be
> fired.
>>> This would allow user defined actions to take place as soon as the
> relevant
>>> option is processed.
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=101230300911853&w=2
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=104690244101751&w=2
>>
>> I'd leave this out for a while.  It sounds like some of functor
>> stuff that was mentioned before.
>
>
> #24040
>
>>
>>> 3.2) RegularExpressionValidator
>>>
>>> A validator should be supplied allowing values to be checked against
> regular
>>> expressions.
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=103951380212779&w=2
>>
>> +1
>
> #24041
>
>>
>>>  ======== Default Values ========
>>>
>>> 4.1) Default Values at Definition Stage
>>>
>>> When creating Arguments the default value(s) are often already known.
> It
>>> might make sense to allow default's to be supplied when building the
>>> Argument instance.
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=101027884006565&w=2
>>
>> +1
>
> #24042
>
>>
>>> 4.2) Default Values from Properties object
>>>
>>> When processing a command line it would be useful to be able to take
> default
>>> values from a properties object.  This way user/project/system
> preferences
>>> could be applied automatically.
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=101027884006565&w=2
>>
>> +1 - should be an abstract solution with impls for particular forms
>> (e.g. props, prefs).
>
> #24044
>
>>
>>> 4.3) CommandLine state can be written to Properties
>>>
>>> This would allow command line defaults to be saved for the next
> invocation
>>> (see "Default Values from Properties object").
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=103731591230259&w=2
>>
>> +1 - a Writer to 4.2's Reader
>
> #24045
>
>>
>>> 4.4) Defaults supplied at interrogation stage
>>>
>>> CLI1 allows defaults to be supplied at the point of interrogation,  
>>> CLI2
>>> should do the same.
>>
>> +1
>
> #24046
>
>>
>>>  ======== Construction and Wrapping ========
>>>
>>> 5.1) Reflection Builder
>>>
>>> It should be possible for CLI to use reflection on a bean and  
>>> provide a
>>> command line interface to it.
>>>
>>> Bug#: 20211
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=104288286123791&w=2
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=106651701602044&w=2
>>
>> +1 this will be very useful
>>
>>> 5.2) Interaction with Commons-Configuration
>>>
>>> A configuration instance could be automatically filled according to  
>>> the
>>> contents of a CommandLine instance.
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=104697467907519&w=2
>>
>> I need to do some research on commons-configuration I haven't managed
>> to look at it yet.
>
> Absolutely - haven't looked at more than the component description yet  
> :(
>
> #24047
>
>>
>>> 5.3) XML 2 CLI
>>>
>>> It would be useful to be able to generate a CLI from an xml file.   
>>> This
>>> would generate the necessary options and provide a CommandLine  
>>> wrapper
> for
>>> type safe interrogation.  The xml might also be used to produce more  
>>> in
>>> depth help than just the online version.
>>>
>>>
> http://marc.theaimsgroup.com/?l=jakarta-commons- 
> dev&m=106028080301621&w=2
>>
>> +1 another long touted feature that must be done.  I don't see it as
>> being necessary for a 2.0 release though.  I have plenty XSL  
>> experience
>> to do this.
>
> #24048
>
>>
>>> 5.4) Generated Ant Task from CLI
>>>
>>> Some mechanism would be supplied to allow Ant tasks to be generated  
>>> that
> are
>>> equivelant to the user's CLI configuration.
>>>
>>> Bug#: 10543
>>
>> +1 a nice integration feature
>>
>>
>> -John K
>>
>>>  ======== CLI2 Take up ========
>>>
>>> 6.1) Persuade/Patch clients to try CLI2
>>>
>>> Fairly obvious one really, but we need to test the new setup with  
>>> known
>>> clients.
>>>
>>> 6.2) Easy migration from CLI1
>>>
>>> We should make an effort to ease migration from CLI1 to CLI2.  One
> option is
>>> to wework CLI1 API to delegate to CLI2 model for functionality.   
>>> Another
>>> angle is to provide a utility class to take a CLI1 model and convert  
>>> it
> into
>>> CLI2 equiv, allowing the cli1 model to be interrogated with cli2
> methods.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> -- 
>> John Keyes <jbjk@mac.com>
>>
>>
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message