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 Wed, 22 Oct 2003 14:45:12 GMT

----- Original Message ----- 
From: "Rob Oxspring" <roxspring@imapmail.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Wednesday, October 22, 2003 3:19 PM
Subject: [CLI] 2.x Tasks


> I've been trawling through the mail archives and open bugs to try and
> produce a comprehensive task list for CLI2.  The list is broadly broken
down
> into 6 sections and also contains a couple of items from my head.  If we
can
> weed out any nonsense and add any missing tasks I'll then go through and
> create/ammend bugzilla entries, after that we can try and figure out which
> are needed for 2.0 and which can be deferred for 2.x.
>
> I've got ideas on how to tackle some of the issues but I'll follow up with
> comments on them separately.
>
> Anyway the list follows.
>
> Rob
>
>
>
>
>
>
>
>  ======== 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.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.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
>

All of the above should all be pretty easy to do, and I've got no strong
opinion on any of them.

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

These two should be pretty straight forward - Group and CommandLine should
take a deal with a List of options instead/as well as the current Set.

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

I suppose we could do this but the loop+switch approach doesn't seem any
easier/shorter than the if/else approach to me.  Haven't thought in depth
though.

>
> 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 guess we could add a Bag (either depend on collections or use
Map<Option,Integer>) for the options and a getOptionCount() method.

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

One that occurred to me while reading about the initial reasons/code for the
"--" option.  Should make things even more flexible.

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

Could be implemented as Validators but the class/method names seem wrong
then.  Not sure this is a huge problem though as I think the use as triggers
will be pretty rare.  Soft dependancies on [functor] should probably come
when [functor] gets a 1.0 release.

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

We could allow defaults to be taken from another CommandLine instance (a la
Properties) and then provide extra "parsers" to create CommandLine instances
from Properties, jdk14 prefs, commons-configuration etc.  This would
ultimately allow multiple levels of defaults from an expanding range of
sources.

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

I can see how this would be useful, and approached as mentione above could
work equally for prefs / commons configuration etc.

>
> 4.4) Defaults supplied at interrogation stage
>
> CLI1 allows defaults to be supplied at the point of interrogation, CLI2
> should do the same.
>
>
>
>  ======== 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
>
> 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

See 4.2 / 4.3 for thoughts.

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

I'm thinking that little more than an XSL/DVSL style sheet should be enough
to do the job.

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

If we got the xsl/dvsl route for xml2cli then I'm pretty sure the same
approach should work well for ant.

>
> Bug#: 10543
>
>
>
>  ======== 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
>
>


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