On 28/04/2025 16:22, Ben Hutchings wrote:
It turns out that it is possible to do this from the slf4j side, by
replacing the Slf4jLogFactory class. See the attached patch. With
the patch applied and libsurefire-java downgraded, the tests pass.
Slf4jLogFactory is called from LogFactory which is already replaced by
slf4j, so I don't think replacing Slf4jLogFactory if useful if
jcl-over-slf4j is already on the classpath.
I recommend disabling the slf4j tests for now.
That would be unfortunate. And I wonder if we wouldn't end up with the
same issue in sfl4j's reverse-dependencies.
A few unit tests may break, but that shouldn't affect applications at
runtime since commons-logging and jcl-over-slf4j shouldn't be
simultaneously on the classpath.
For example pdfsam has jcl-over-slf4j.jar in /usr/share/pdfsam/lib/ but
not commons-logging.jar. Same thing for Maven in /usr/share/maven/lib/.
openrefine on the other hand has both (in
/usr/share/openrefine/webapp/WEB-INF/lib/) and that seems wrong.
Actually I am confused by this: I was able to build with everything else
from current unstable and only libsurefire-java downgraded.
So I wonder just how incompatible that plugin really is.
Of course it could be that the incompatibility causes a quiet fallback
somewhere and that is what avoids the hang.
It's source and binary incompatible, but the report plugin is never used
in Debian (it generates an HTML report of the unit tests, we never use
that when building packages), so it never blows up.
We could try restoring the reporting plugin, but commenting the
incompatible code. That may be enough to fix the freezing tests.
Anyway, I think I am done with this bug. Good luck!
Thanks again for the help, it's nice to have a kernel guru tackling
Maven issues :)
Emmanuel Bourg
