We'll be following OSGi standards as ultimately Maven will run in an
OSGi runtime. So whatever best practices are there we will follow as
far as package structure.
On 2009-11-16, at 9:16 AM, Kristian Rosenvold wrote:
I'm trying to make some further adjustments to the concurrency
features
proposed to MNG-3004. I have read all the faq's and the
maven coding standard. This is probably an old can of worms, so I'll
try to
keep this question simple:
It seems to me like the predominant standard for inner classes in
what I've
seen of the code base is the "hide everything approach"
with private inner classes. While a great strategy in the
information hiding
department, it is a suboptimal strategy in the unit-testing
perspective since it basically forces you to test the class as a
whole. It
also has a tendency to create extremely large class files
(DefaultLifeCycleExecutor which I'm looking at now has 2100 lines or
so).
Testing 2100 lines of code through only a few front-facing methods
is really
cumbersome and usually misses out quite a few of the interesting
details.
It's like trying to take portait photos through satelite imagery.
I know there are several ways of achieving this, with different
kinds of
strengths/weaknesses. Personally I tend to favour the "internal"
subpackage
(e.g. org.apache.maven.lifecycle.internal), because it avoids
polluting the
namespace of your public artifacts with non-public stuff (and
strictly, the
inner class X when exposed through class Y becomes part of the api
for Y).
Package level protection for the test-exposed stuff is also nice,
better
than "protected/subclassing".
Is there any consensus on how this should be done to get unit-
testability?
Maybe something could be written in the coding standard ?
Kristian Rosenvold
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
