[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [CLI] Refactoring plans
From:       John Keyes <jbjk () mac ! com>
Date:       2004-01-31 10:52:10
Message-ID: 8546A3AB-53DB-11D8-8D4E-00039379521C () mac ! com
[Download RAW message or body]

Hi Rob,

> This is just a quick heads up to let you know what I've got planned in 
> the next few days for the cli2 package (on the ROXSPRING branch) it's 
> mostly refactoring and minor stuff before I get back to experimenting 
> with option paths.
>
> 1) Refactor CommandLine.  This class is getting pretty big and I'm 
> hoping I can rationalise it a little, firstly by extracting readonly 
> and writeable interfaces, and then probably moving some (potential) 
> functionality to decorators.
>
> CommandLine << interface
> WriteableCommandLine << interface
> CommandLineImpl << implements both of above
> TypedCommandLine << decorates CommandLine (provide typed getValue() 
> varients)
> DefaultingCommandLine << decorates CommandLine (defaults provided by 
> alternative CommandLine or maybe configuration?)

Sounds good.

> 2) Repackage some cli2.  Currently there are 33 classes/interfaces in 
> the cli2 package and I'd like to reduce that.  I'm not sure which 
> direction I'll end up going but possibilities include the following:
> o.a.c.cli2.api - the interfaces and OptionException
> o.a.c.cli2.impl - the implementations and other exceptions
> o.a.c.cli2.commandline - the refactored CommandLine and friends
> o.a.c.cli2.help - Help*

Not sure about creating the api package.  Why not keep these interfaces 
in the cli2 package?

> An alternative would include subpackages based on the 
> argument/group/parent separation but I don't see that getting us 
> anywhere.

Nah, the first suggestion is better.

> 3) Reformat some code.  There is a slight mix of code formatting 
> involved currently and I'd like to pick one and bring the source in 
> line using either checkstyle and some nagging or jalopy.  Currently we 
> appear to have slightly fewer checkstyle errors if we use the sun 
> settings rather than turbine (5290 vs5640) or we could hack at a 
> checkstyle config and come to a custom conclusion.  I think I'm 
> leaning towards to sun style but am open to suggestions.

Fine, lets pick one (I'm not fussed about which one is chosen).  Lets 
stick
to it then.

If you get the chance you could change the license to version 2.0 as 
well.  This license can be included by reference in each source file.

-John K
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]