Please publish an EclEmma release built against JaCoCo 0.8.15

13 views

Skip to first unread message

Heiko Selber

unread,

Sep 8, 2026, 7:46:34 AMSep 8

to JaCoCo and EclEmma Users

Hi,

the newest published EclEmma is 3.1.11 (2025-11-26), bundling JaCoCo 0.8.14.

JaCoCo 0.8.14 declares org.objectweb.asm and org.objectweb.asm.commons as [9.9.0,9.10.0).

On master, "Upgrade JaCoCo to 0.8.15" (#137) landed on 2026-06-08 and "Add Eclipse 4.41
target platform" (#136) on 2026-06-12. JaCoCo 0.8.15 uses ASM 9.10.1. But no release
carries it, so every current Eclipse installation still gets the 0.8.14 pin.

Why this matters beyond staying current:

In an Eclipse installation, org.jacoco.core is currently the *only* thing pinning
org.objectweb.asm.commons to 9.9.x. Eclipse Orbit's 2026-09 aggregation ships the whole
ASM family at 9.10.1. When p2 upgrades asm, asm.tree, asm.tree.analysis and asm.util to
9.10.1 but has to leave asm.commons at 9.9.1 because of JaCoCo, the resulting bundle set
is p2-valid but OSGi-unresolvable: org.apache.aries.spifly ends up exposed to two
conflicting wirings of the org.objectweb.asm package and fails with a uses-constraint
violation. On Eclipse 4.36 and newer this cascades all the way into the workbench not
starting at all, because org.eclipse.jface and org.eclipse.ui mandatorily require the
SVG capability that ultimately depends on spifly.

Concrete instance: Eclipse 4.40.0.20260604-0652 with EclEmma 3.1.11 / JaCoCo 0.8.14 —
the IDE would not start after a routine p2 update. Same failure reported in
eclipse-platform/eclipse.platform#2833, eclipse-platform/eclipse.platform.ui#4038 and
eclipse-oomph/oomph#203.

A released EclEmma built on JaCoCo 0.8.15 would remove the last obstacle to moving the
ASM family to 9.10.1 in one piece.

Is a 3.1.12 release planned?

Regards,

Heiko