commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <roxspr...@imapmail.org>
Subject [CLI] 2.x Tasks
Date Wed, 22 Oct 2003 14:19:29 GMT
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

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



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

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

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.

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

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

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

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

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

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



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


Mime
View raw message