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 Wed, 22 Oct 2003 15:07:13 GMT
>  ======== 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 

> 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

> 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

> 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

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)

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

> 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

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

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

> 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

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

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

> 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

> 4.4) Defaults supplied at interrogation stage
> 
> CLI1 allows defaults to be supplied at the point of interrogation, CLI2
> should do the same.

+1

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

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

> 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


Mime
View raw message