Sean Owen wrote:
Could be. I took an indirect stab at mitigating possible sources of
this issue by increasing encapsulation in the tests -- I still believe
fields should never by non-private. This may start to surface the
behind-the-scenes dependencies and side effects that shouldn't be
there. But the issue, if you're right, probably concerns too much
static stuff.
What tests are failing?
I tried -X, --error and --debug options but none gave me any more
resolution on the problem. Thinking this might be an initialization
issue, I commented out the two assertEquals statements in
../dirichlet/TestMapReduce.testMapper() and .testReducer() and now the
Maven install runs just fine. So, it looks to me like a recent change to
the way random numbers are initialized introduced the problem. I don't
know why nobody else is seeing this, since I have not changed either of
those two tests.
When run from Eclipse one test class at a time, the random number
generator is initialized one way and the two tests pass. During the
Maven run; however, it is initialized differently (or not at the start
of the test) and so these two tests produce different numbers of mapper
partitions (collector keys) and those two tests fail.
I'm going to check in the modified tests - with no asserts - while we
sort out the random number seeding or I figure out a better way to do
the tests. Testing Dirichlet is darn difficult because all of the
random-induced moving parts.
