First, the hackyTelemetry module contains the org.hackystat.app.telemetry package hierarchy, which includes lots of subpackages. One of these subpackages is org.hackystat.app.telemetry.processor.reducer.impl, which includes a bunch of Reduction function implementation classes (ActiveTimeReducer, BuildReducer, etc.). So far, so good.
Second, the hackyPerf module contains the org.hackystat.app.perf package hierarchy, with subpackages for daily analysis and daily project. This is also good. However, the hackyPerf module also contains its own copy of the org.hackystat.app.telemetry.processor.reducer.impl package, with its performance reduction function classes in it. This is Not Good.
As a general rule, let's not "tangle" the package hierarchy by putting some of the classes associated with a package in one module and other classes associated with this same package in another module. In the current case, some of the classes associated with the package org.hackystat.app.telemetry.processor.reducer.impl are in the hackyTelemetry module and other classes associated with this package are in the hackyPerf module. If this practice becomes widespread, it will be really difficult to understand the system.
To solve the current problem, I'm going to create a new package in hackyPerf called org.hackystat.app.perf.reducer, and put the reduction function classes for performance analysis in there.
Cheers, Philip
