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
