commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <roxspr...@imapmail.org>
Subject Re: [CLI] 2.x Tasks
Date Thu, 23 Oct 2003 09:31:10 GMT
----- 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


Mime
View raw message