I just stumbled across the maven modules, and wanted to bring up some hopefully minor issues.
Currently, there are two modules associated with maven: hackySensor_JUnitMaven with package hierarchy org.hackystat.sensor.junit.maven hackySensor_LoccMaven with package hierarchy org.hackystat.sensor.locc.maven Upon reflection, there are a couple of issues I see with this packaging approach: (1) The module name does not reflect the package hierarchy in the standard fashion. For example, the FindBugs autoconfig code directly generates a package prefix from the module name. This approach breaks down for these two modules, since FindBugs will generate org.hackystat.sensor.junitmaven, not org.hackystat.sensor.junit.maven (2) One of the Version 7 architectural precepts was that there should be a one-to-one mapping between the contents of modules and the top four levels of the hackystat package hierarchy. The above approach breaks this architectural convention, since (for example) the package hierarchy org.hackystat.sensor.junit now maps to the contents of two modules: hackySensor_JUnit and hackySensor_JUnitMaven. The lack of a one-to-one mapping makes the module-level structure of the system less transparent. One solution is to have a single module called hackySensor_Maven containing the package hierarchy org.hackystat.sensor.maven.*. Subpackages for locc, junit, etc. can be created inside this package. Does anyone (or, more particularly, does Aaron :-) see any problems with refactoring into this package-level format? I'm not familiar enough with Maven to assess the implications of this proposal. Cheers, Philip
