Is there any way to skip Gradle Instrumenting Classpath File Transformer?

Some users of the jackson-core lib want to upgrade to latest jackson-core but they claim to not be able to upgrade to latest Gradle versions. jackson-core 2.15.0-rc1 is a multi-release jar and includes some META-INF/versions/19 classes.

InstrumentingClasspathFileTransformer uses asm jar and the old asm jar in Gradle 7.5 and before cannot parse Java 19 classes.

Ideally, InstrumentingClasspathFileTransformer should skip classes in META-INF/versions/X dirs - at least for Java versions that that Gradle version does not support.

Is there any possible workaround like disabling InstrumentingClasspathFileTransformer?

The related issue is Gradle 7.4 fails on multi release jar's with JDK 19 code · Issue #24390 · gradle/gradle · GitHub

You cannot disable that transformer afaik and it would also be quite problematic if you could. The transformation done for example determines actions incompatible with configuration cache and also determines configuration cache inputs automatically like read system properties, environment variables, and so on.

There should only be a problem though if that dependency is to be used in Gradle build logic. While a fix for that issue should probably be added, in the meantime the work-around probably simply is to also update Gradle to a version that supports Gradle 19.

Thanks Björn. I would always gladly upgrade. I am one of those unfortunate lib maintainers who gets people complaining about the lib I work on because they decide they won’t upgrade Gradle.

A helpful reviewer on that Jackson issue pointed out that the issue only affects Gradle 7.4/7.5 when the jackson-core multi-release jar is referenced in the buildscript dependencies.

only affects Gradle 7.4/7.5

The transformer is there since Gradle 6.5 afair.

when the jackson-core multi-release jar is referenced in the buildscript dependencies.

Yes, that’s what I also said above:

That can mean that some plugin depends on the lib, or that some lib a plugin depends on depends on that lib, or that someone adds it using buildscript { ... } block to the build script classpath, …