Hi Michel,
this is probably possible. As a starting point I would implement a
ICoverageVisitor which combines IClassCoverage instances under certain
conditions (e.g. same name). The interesting point is the merge
algorithm itself: In your case (classes have same structure) it is
probably real
Thanks Marc for taking a look. Maybe there is a way for me to use the JaCoCO
APIs to perform my own "merging"? I'm not sure how pluggable the APIs are with
JaCoCo, because most of the time it "just works" for me and I haven't had to do
anything on my own!
On Tuesday, February 20, 2018 at 1:02:0
Hi Michael,
thanks for the details! Indeed a variable name and a value in the
constant pool are different. This leads to a different class id which is
simply the CRC64 checksum of the raw class file. So current JaCoCo will
not be able to merge them.
The tricky question is how and under what cir
Using the IntelliJ decompiler for one instance shows:
//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//
package com.mkobit.libraryexample;
import com.cloudbees.groovy.cps.Builder;
import com.cloudbees.groovy.cps.MethodLocation;
import com.cl
Hi,
do you have an idea what is the actual difference between the class
files?
You can decompile the different class versions with javap -p -c and diff
the result.
Regards,
-marc
On 2018-02-17 00:21, mko...@gmail.com wrote:
I'm working on a Gradle plugin
(https://github.com/mkobit/jenkin
