What is the problem the feature request solves?
JaCoCo was added in #163 to publish JVM coverage to Codecov. #3381 removed the codecov/codecov-action@v5 step, which was the only consumer of the output. The plugin itself was left behind, so every Maven build still:
- prepends
-javaagent:org.jacoco.agent... to argLine, instrumenting every class loaded in every forked test JVM (both surefire and scalatest), and
- runs
jacoco:report in the test phase, for all four modules.
Nothing reads the result. It is written to <module>/target/site/jacoco/ and <module>/target/jacoco.exec; no CI step uploads it, no jacoco:check rule gates on it, and no path anywhere in the repo references it.
The only surviving hint of the original intent is actively misleading. The upload-test-reports input in .github/actions/java-test/action.yaml is still documented as "Whether to upload test results including coverage to GitHub", but the step it guards globs **/target/surefire-reports/*.txt only. So the one job that opts in (pr_build_linux.yml) advertises a coverage upload that has not happened since February.
It is not free. On a local run in which zero tests executed, jacoco:report still produced 59 MB across 2182 files for the spark module alone — a 15 MB jacoco.xml plus the full HTML site — and that happens on every job in the PR matrix.
It is also not configured to measure anything useful even if someone did look:
- There is no
report-aggregate. Each module reports against its own jacoco.exec only. common has zero test sources, so common/target/jacoco.exec is never written and the goal logs "Skipping JaCoCo execution due to missing execution data file" on every build — while the 6 classes in common/src/main are in fact exercised by the 248 test files in spark. Comet's actual coverage of common reads as nothing.
- Comet's native Rust code is out of scope for JaCoCo entirely, so even a correct JVM number would describe a minority of the codebase.
Describe the potential solution
Remove the plugin from pom.xml and fix the stale input description. If JVM coverage is wanted again later, it should be reintroduced together with a consumer — an aggregate report plus an upload or a threshold — rather than as a report generated into a directory nobody opens.
Additional context
No changes to test JVM arguments other than dropping the agent: argLine stays -ea -Xmx4g -Xss4m ${extraJavaTestArgs}.
What is the problem the feature request solves?
JaCoCo was added in #163 to publish JVM coverage to Codecov. #3381 removed the
codecov/codecov-action@v5step, which was the only consumer of the output. The plugin itself was left behind, so every Maven build still:-javaagent:org.jacoco.agent...toargLine, instrumenting every class loaded in every forked test JVM (both surefire and scalatest), andjacoco:reportin thetestphase, for all four modules.Nothing reads the result. It is written to
<module>/target/site/jacoco/and<module>/target/jacoco.exec; no CI step uploads it, nojacoco:checkrule gates on it, and no path anywhere in the repo references it.The only surviving hint of the original intent is actively misleading. The
upload-test-reportsinput in.github/actions/java-test/action.yamlis still documented as "Whether to upload test results including coverage to GitHub", but the step it guards globs**/target/surefire-reports/*.txtonly. So the one job that opts in (pr_build_linux.yml) advertises a coverage upload that has not happened since February.It is not free. On a local run in which zero tests executed,
jacoco:reportstill produced 59 MB across 2182 files for thesparkmodule alone — a 15 MBjacoco.xmlplus the full HTML site — and that happens on every job in the PR matrix.It is also not configured to measure anything useful even if someone did look:
report-aggregate. Each module reports against its ownjacoco.execonly.commonhas zero test sources, socommon/target/jacoco.execis never written and the goal logs "Skipping JaCoCo execution due to missing execution data file" on every build — while the 6 classes incommon/src/mainare in fact exercised by the 248 test files inspark. Comet's actual coverage ofcommonreads as nothing.Describe the potential solution
Remove the plugin from
pom.xmland fix the stale input description. If JVM coverage is wanted again later, it should be reintroduced together with a consumer — an aggregate report plus an upload or a threshold — rather than as a report generated into a directory nobody opens.Additional context
No changes to test JVM arguments other than dropping the agent:
argLinestays-ea -Xmx4g -Xss4m ${extraJavaTestArgs}.