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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
