any reason why you keep kicking of the mailing list ? :)
>> We disable jacoco because emma and jacoco may cause test
failures when running together (conflictual instrumentations probably).
>> Before, jacoco without emma was what happened by default (hudson was jacoco +
emma). I just disabled jacoco; but I can wrap it into a profile if you want. But I am not
sure it will make it more used/helpful if we have to trigger it and ensure we don't
have jacoco and emma at the same time.
>>
> can't coverage just be -Pcoverage and then have a property that decides which is
used ?
>
> -Pcoverage runs jacoco by default
> -Pcoverage -Demma switches it to emma and is what is used in hudson/jenkins until we
got reporting up and running ?
>
emma and jacoco are very distinct.
What would you think of -Pcoverage-emma and -Pcoverage-jacoco?
I would then choose -Pcoverage and -Pcoverage-emma.
> And at least Denis and I do look at coverage from time to time.
Cool, and what do you look at exactly?
the jacoco.exec file generated by hudson builds, or the emma reports
in hudson jobs?
the reports to see where things are bad/good - haven't had time to try out jacoco
loading (and its also tricky since need the exact same .class files to load it properly)
I guess you would be fine with Emma reports, and delay real usage of
Jacoco to the day it will have reports in hudson (or on
sonar.jboss.org, but I bet it will
appear after a good jacoco/jenkins report plugin).
It seems to be impossible (at least for some projects - namely VPE and JSF) to get
jacoco.exec and emma reports at the same time.
We have to keep Emma currently, so if you are happy with it, it is not useful to maintain
jacoco usage until we use it to fully replace Emma.
I would prefer we push jacoco as much as possible for QE and local usage over Emma.
/max