That makes sense as far as Patricia's question goes and assuming her tests fitted nicely in those boxes.
The modular build tangent we've gone off on is not so easily satisfied. I agree with Peter that modularising the build to allow different parts of River to evolve at different places *more easily* is a noble goal and one worth pursuing. I think, and please correct me if I'm wrong, is that not all the tests fit into such nice individual buckets. We are indeed very lucky to have such a thorough test suite, but not all the tests have single intentions and so not all the tests are going to fit into the same clean modules that the production code does. I get the feeling that we'll need a separate modularising strategy to deal with the tests than we do with the production code. Maybe I'm barking up the wrong tree? On Monday, February 28, 2011, Dennis Reedy <[email protected]> wrote: > > On Feb 28, 2011, at 1247AM, Patricia Shanahan wrote: >> >> How would you propose handling a case like outrigger.FastList? >> >> It is package access only, so changing its interface to the rest of >> outrigger did not affect any public API. Several classes needed to be >> changed to handle the interface change. > > If I understand your question correctly, I think it should be fairly > straightforward. Following module conventions, we would have a structure that > would look (something) like: > > outrigger/src/main/java/org/apache/river/outrigger > outrigger/src/test/java/org/apache/river/outrigger > > The test (or benchmark) code would be in the same package, just in a > different directory. You would be able to accommodate your package access > only requirement. > >
