(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
I think I like this approach better, because I'm not sure how to
create a Maven pom.xml file that will separate the maven plugins in
the hackySensor_Maven approach.
Currently, I'm under the impression that we have to build the maven
sensors (plugins) with Maven, because Maven creates the packaging
structure that the plugins need. However, its my belief that we can
still build (compile and test) these hackySensor_<name>Maven modules
with our current Ant build process; we just can't deploy them in the
same manner.
thanks, aaron
At 12:52 PM 2/20/2006, you wrote:
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
