Cannot run Quarkus tasks with dependencies from an external project using Gradle composite build

[n-hass]

Describe the bug

When using a Gradle composite build, if an includeBuild supplies a JAR with an external dependency that is common with the Quarkus project, it may cause classloader issues.

ClassCastException: class MyClass$$serializer cannot be cast to class kotlinx.serialization.SerializationStrategy (MyClass$$serializer is in unnamed module of loader 'app'; kotlinx.serialization.SerializationStrategy is in unnamed module of loader io.quarkus.bootstrap.classloading.QuarkusClassLoader @dcfda20)`

I have only observed this with kotlinx-serialization on the following reproducer: https://github.com/n-hass/quarkus-issue-47430
It can be replicated by running the quarkusTest task on :application-server:services:foo.

The layout is as so:

Project A
├── includes: Project B
│   └── uses: kotlinx-serialization
└── uses: kotlinx-serialization

Expected behavior

A dependency on an includeBuild artifact does not cause a ClassCastException when using it in Quarkus

Actual behavior

kolinx-serialization's generated classes are being loaded using the system classloader, whilst the project's serialization dependency in the quarkus classloader, causing the exception.

How to Reproduce?

1. Clone https://github.com/n-hass/quarkus-issue-47430
2. run ./gradlew :application-server:services:foo:quarkusTest

Output of uname -a or ver

Darwin NM 24.4.0 Darwin Kernel Version 24.4.0: Fri Apr 11 18:32:50 PDT 2025; root:xnu-11417.101.15~117/RELEASE_ARM64_T6041 arm64 arm Darwin

Output of java -version

openjdk version "21.0.4" 2024-07-16 LTS OpenJDK Runtime Environment Zulu21.36+17-CA (build 21.0.4+7-LTS) OpenJDK 64-Bit Server VM Zulu21.36+17-CA (build 21.0.4+7-LTS, mixed mode, sharing)

Quarkus version or git rev

3.20.0

Build tool (ie. output of mvnw --version or gradlew --version)

8.13

Additional information

#47730 fixes the test part of the reproducer provided by @n-hass but not the quarkusTest one, unfortunately. We'll need to investigate it further.

Originally posted by @aloubyansky in #47430

[quarkus-bot]

/cc @geoand (kotlin), @glefloch, @quarkusio/devtools

[gsmet]

@aloubyansky I suppose this one is a puzzle for you.

[n-hass]

Is this actually just a problem with the generated code from kotlinx-serialization? I only seem to be able to replicate it with serialization classes.

[n-hass]

The observed behavior may have changed (for the worst?) with 3.23.0.

When running quarkusDev, Quarkus complains about the types from the external project on startup:

Failed to index com.MyClass: Class does not exist in ClassLoader QuarkusClassLoader:Deployment Class Loader: DEV@19e7a160
Class for name: com.MyClass was not found in Jandex index. Please ensure the class is part of the index.

Which I am assuming is then the cause of the later fatal:

 Failed to start quarkus: java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
        [error]: Build step io.quarkus.arc.deployment.ArcProcessor#registerBeans threw an exception: java.lang.IllegalArgumentException: Producer method return type not found in index: com.MyClass
        at io.quarkus.arc.processor.Types.getProducerMethodTypeClosure(Types.java:442)
        at io.quarkus.arc.processor.BeanDeployment.findBeans(BeanDeployment.java:1316)
        at io.quarkus.arc.processor.BeanDeployment.registerBeans(BeanDeployment.java:291)
        at io.quarkus.arc.processor.BeanProcessor.registerBeans(BeanProcessor.java:155)
        at io.quarkus.arc.deployment.ArcProcessor.registerBeans(ArcProcessor.java:435)
        at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:733)
        at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856)

Naturally the Test classloader has the same fatal failure with quarkusTest.

I'm not sure what I'm looking at or for, but my generated Jandex index from the module in use does contain strings of the full package name of the external class referenced in the failure log. Using empty beans.xml files had no change, and adding a quarkus.index-dependency.company.group-id configuration does not change anything either.

This bug is blocking me from separating two independent projects because of my Quarkus' dependency on the other. Are there any workarounds?

[aloubyansky]

@n-hass I'm finalizing a few other but related fixes. I'll look into this one next.

[n-hass]

Thank you @aloubyansky

Let me know if you'd like more logs, snippets, or new reproducers. Happy to provide you what you need.

[n-hass]

Ah @aloubyansky I found it! The bug is triggered when the external dependency is from a Kotlin Multiplatform project.

I have a reproducer here: https://github.com/n-hass/quarkus-issue-47734

The external project (let it be called shared) which is an includeBuild of the server (server <- shared) is built as a multiplatform project with JVM and JS targets. With more than just the JVM target enabled, the bug is triggered and the classes from it are not indexed, giving the failure in Quarkus. Hence, you can disable the JS target in the shared project, have it build multiplatform with only a JVM target, and then Quarkus will start successfully.

I can confirm the same behavior in my real project - disable all non-JVM targets in the shared project and Quarkus works.

Sorry for the double ping :)