maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Drury, Tim" <t.dr...@sap.com>
Subject RE: Cobertura instrumentation in complex projects
Date Tue, 06 Mar 2012 17:13:13 GMT
I've done exactly this and it's a pain.  I didn't want cobertura-instrumented jars from possibly
infecting our production jars, so I have a Jenkins project that uses a private maven repo
to build the entire product.  The final deliverable has a "cobertura" classifier and this
is deployed to Artifactory.  Another Jenkins project runs daily to pick up this artifact and
deploy it to our integration test server.

However, all this is only the start of your problems.  Getting cobertura data files from the
integration server in an automated fashion is very hard.  I had to write a web service to
fetch the data from the (well documented) cobertura static class and return it to the caller.
 After my integration test cases run, a maven plugin I wrote fetches that data, and I use
the Jenkins cobertura plugin to turn it into html reports.  

I'm in the process of scrapping all that in favor of jacoco which instruments the code on-the-fly
via a javaagent running in the container.

-tim

-----Original Message-----
From: Jim McCaskey [mailto:jim.mccaskey@pervasive.com] 
Sent: Tuesday, March 06, 2012 12:00 PM
To: 'users@maven.apache.org'
Subject: Cobertura instrumentation in complex projects

Hello all,

I have a fairly large build in which we use cobertura extensively to look at unit test code
coverage for our project.  We also have separate integration tests that we would like to run
using these instrumented binaries.  There is some good documentation on how to accomplish
that here:

http://mojo.codehaus.org/cobertura-maven-plugin/instrumentingDeploymentArtifact.html

While that would work for a simple case, I'm struggling with trying to visualize how this
would work in a complex case.  We have several separate builds that accumulate to make up
the install package that we then push to our integration testing systems.  So everyone one
of our couple hundred jar's which are fed from all these builds would need to be published
to a Maven repository so that the install builds could pick them up.  But if I push them to
my standard SNAPSHOT repository it would overwrite my existing non-instrumented versions.

We only envision needing this run on a nightly basis.  One suggestion that has been proposed
is to do the "publish with classifier" thing and a profile that turns on cobertura.

https://maven.apache.org/plugins/maven-deploy-plugin/examples/deploying-with-classifiers.html

Frankly, I'm not sure how that plumbing would work at this point, but I suppose it's possible.
 Having said that, I think we just got done having that conversation on this list and the
answer is that that is "not the maven way".

I'm positive I'm not the first one in this boat.  Any thoughts?

-Jim





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message