Hey folks, I'm working on gathering coverage data across all of our test suites. The jvm-dtest-upgrade suite is currently unfriendly to Jacoco: it uses classes from multiple versions of Cassandra but with the same class names, so Jacoco's analysis fails due to "Can't add different class with same name"[1]. We need a way to exclude alternate-version classes from Jacoco's analysis, so we can get coverage for the current version of Cassandra.
Jacoco supports exclusion of classes based on class name or classloader name, but the class names are frequently usually identical across Cassandra versions. The jvm-dtest framework doesn't name classloaders, so we can't use that either. I'd like to propose that we name the jvm-dtest InstanceClassLoader instances so that some can be excluded from Jacoco's analysis. Instances that create new InstanceClassLoaders should be able to provide an immutable name in the constructor. InstanceClassLoader names should indicate whether they're for the current version of Cassandra (where coverage should be collected) or an alternate version. If classloaders are appropriately named in the current versions of Cassandra, we should be able to test upgrade paths to that version without updating the older branches or building new jvm-dtest JARs for them. Any objections or alternate approaches? -- Abe [1]: More specifically: Jacoco uses class IDs to map the analysis data that's produced during text execution to .class files. I'm configuring the Jacoco agent's classdumpdir to ensure that the classes loaded during execution are the same classes that are analyzed during report generation, as is recommended. When we build the alternate version JARs for jvm-dtest-upgrade, we end up with multiple classes with the same name but different IDs.
