Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <000d01c3e748$f0f622b0$7a9b10ac@risc.uk>
Reply-To: "Rob Oxspring" <roxspring@imapmail.org>
From: "Rob Oxspring" <roxspring@imapmail.org>
To: "John Keyes" <jbjk@mac.com>,
	"Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: [CLI] Refactoring plans
Date: Fri, 30 Jan 2004 15:51:34 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

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

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*
An alternative would include subpackages based on the =
argument/group/parent separation but I don't see that getting us =
anywhere.

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.

If anyone has any thoughts, wisdom, questions or suggestions they're all =
welcome,

Rob

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