> I think I like [the current] 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.

Maybe we're thinking about Hackystat-Maven integration in the wrong way.  The 
current approach is going to lead to dozens of modules called 
hackySensor_<Sensor>Maven, each of which will contain very little actual code 
(the JUnit maven module basically contains a single class with maybe 100 LOC.)  

Instead, why not have one single module called hackySensor_Maven that builds a 
single jar file containing all of the sensors? Then, for the pom issue, you 
have a choice of either:

(a) a single pom.xml file that can define all of the sensors and control 
whether they're enabled.
(b) ant tasks to generate an individual pom.xml file for each sensor.  Each 
sensor would refer to the same hackymaven.jar file (or whatever it's called).

Would this work?
 
> 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.

Actually, they won't integrate into the daily build correctly---as I mentioned 
before, the FindBugs analysis will blow up on these modules once we have them 
and FindBugs in the daily build together. So, we're going to have to do 
something. 

Cheers,
Philip

Reply via email to