I've been looking at how to resolve the jdepend test failure without taking the ignoring approach (up the threshold to 0.3). I went in search of a way to package things better and after thinking it through I came up with the following proposed renamings:
1) o.a.c.c.HelpFormatter -> o.a.c.c.util.HelpFormatter
HelpFormatter strikes me as "quite useful but non-essential" which pretty much describes most .util packages. (My initial thought was for a .help package but nothing else seemed to fit with it)
+0
2) o.a.c.c.HelpSetting -> o.a.c.c.DisplaySetting
HelpSetting is used outside of the help context (i.e. toString()) and all the constants are prefixed DISPLAY_ anyway.
+1
3) o.a.c.c.impl.Comparators -> o.a.c.c.util.Comparators
I searched for candidates to join HelpFormatter and Comparators struck me as "quite useful but non-essential" too.
+0
4) o.a.c.c.impl -> o.a.c.c.options
After 3, .impl is composed of 9 Option implementations and HelpLineImpl which is just part of the Option implementation anyway. Also I wonder if people will avoid touching / investigating .impl packages (as I do) and miss PropertyOption.
+0
5) DefaultOption* -> Flag*
I still have a slight itch about the name 'DefaultOption' and 'Flag' is the best alternative I can remember coming up with.
+0
I think 2 should definitely be done and am fairly sure that 5 is a step forward (anything better than Flag out there??). I'm increasingly comfortable that 1 & 3 make sense to be done together, and 4 is just the logical conclusion.
Actually though, the choice of .options vs .option might open another can of worms; should packages be singular or plural. I think we should rename .builders or .commandline if we come to a decision. Personally plural seems better but I prefer .util to .utils - so I've got double standards internally anyway and could be persuaded either way.
I prefer the singular ;) I'll leave it up to you, I think we should be consistent though, so whatever is decided it should be followed through.
Singular it is then.
Back to the original point, doing 1 & 3 brings the jdepend distance to a maximum of ~0.20 so we can up the threshold to 0.21 and the test will pass too.
<lazyitis>Could you give me some information about this metric? What does it mean?</lazyitis>
The short answer is that it measures how well organised a package is, with 0 being ideal and 1 being a bit of a mess:
"Ideal packages are either completely abstract and stable or completely concrete and instable"
The detail is pretty clearly put on the jdepend website but I'd recommend a cup of coffee before trying to get your head around it:
http://www.clarkware.com/software/JDepend.html#overview.
Rob
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
