Quarkus Gradle leaks "dev" dependencies outside the "quarkusDev*" configurations

[jskillin-idt]

Describe the bug

The "dev" dependencies, in certain scenarios, will appear outside the "quarkusDev" Gradle configurations.

Quarkus appends "dev" dependencies to runtime extensions to satisfy dev mode. In Gradle, this is done the moment the "quarkusDev" configurations are resolved, which is not necessarily when dev mode is activated.

In addition, these dependencies are added by modifying the metadata that Gradle has fetched from Maven Central to append the extra "dev" dependency to the runtime extension. This appears to have a global build-wide impact on anything that references the runtime extension, including the "runtimeClasspath".

Finally, the way Quarkus appends these "dev" dependencies to the tree causes them to suddenly appear late in the dependency tree resolution process, which means that any configurations that had the unfortunate luck of being computed before the "quarkusDev*" configurations (possibly because they came before "q" in the alphabet) will lack those dependencies.

For me, this results in errors like the following, because I have lock files enabled to ensure reproducible results:

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':quarkusGenerateAppModel'.
> Could not resolve all artifacts for configuration ':quarkusProdBaseRuntimeClasspathConfiguration'.
   > Did not resolve 'io.quarkus:quarkus-rest-dev:3.24.4' which is part of the dependency lock state
   > Did not resolve 'io.quarkus:quarkus-vertx-http-dev:3.24.4' which is part of the dependency lock state
   > Did not resolve 'io.quarkus:quarkus-assistant-dev:3.24.4' which is part of the dependency lock state
   > Did not resolve 'io.quarkus:quarkus-arc-dev:3.24.4' which is part of the dependency lock state

Expected behavior

I believe the "dev" dependencies should not leak into any other configuration outside "quarkusDev", and at least shouldn't be resolved while dev mode is not being used.

Actual behavior

As described, "dev" dependencies appear in configurations like "runtimeClasspath", but only when "quarkusDev" configurations are resolved.

How to Reproduce?

Reproducer: https://github.com/jskillin-idt/quarkusio-quarkus-issues-48992

Steps to reproduce:

1. Clone the reproducer. Note that it's just a Quarkus app, but with lock files enabled per Gradle documentation on reproducible builds.
2. Run gradle dependencies --write-locks.
3. Run gradle assemble. Notice that Gradle complains that the "dev" extensions are missing, even though we're not using dev mode for a normal runtime.
4. The gradle dependencies command runs without issue because it simply replays the same result that produced the lock files, showing that at least the way this command resolved dependencies is consistent. 😄

Steps to reproduce on a Quarkus app without lock files enabled:

1. Run gradle dependencies and note that "dev" dependencies appear in the runtimeClasspath configuration.
2. Run gradle dependencies --configuration runtimeClasspath and note that the "dev" dependencies have disappeared. Spooky! 😉

Output of uname -a or ver

Linux 6.12.38 #1-NixOS SMP PREEMPT_DYNAMIC Mon Jul 14 14:02:59 UTC 2025 x86_64 GNU/Linux

Output of java -version

openjdk version "21.0.7" 2025-04-15 LTS OpenJDK Runtime Environment Temurin-21.0.7+6 (build 21.0.7+6-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.7+6 (build 21.0.7+6-LTS, mixed mode, sharing)

Quarkus version or git rev

3.24.4

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

Gradle 8.14.2

Additional information

No response

[quarkus-bot]

/cc @glefloch, @quarkusio/devtools, @radcortez (config)

[jskillin-idt]

Reproducer has been edited in.

[jskillin-idt]

Hmmm. Possibly a better title is:

Quarkus Gradle leaks "dev" dependencies outside the "quarkusDev*" configurations

as really I expect the "quarkusDev" configurations to be "messy" to fit Quarkus' needs in the moment to get dev mode off the ground, whereas I would rather the standard "runtimeClasspath", etc., configurations to remain pure to the purpose of shipping a clean output.

Up to you guys how you want to frame this issue. I could go either way.

[jskillin-idt]

I've decided to rename the issue. I waffled on the name initially, but the dependency locking is really just the way I discovered the issue. That does mean this is preventing my builds from working, but that's a build quality choice I've made and i don't know that Quarkus supports it yet. I'd rather frame the issue in a way that represents something you guys would prioritize based on what you support.

[jskillin-idt]

An incredibly dumb workaround I'm testing, just to get back on my feet, is to make the dependencies task depend on every resolvable "quarkus*" configuration. That seems to at least force Quarkus to be honest before the lock files are built, by resolving those configurations before the dependency report is built for any configuration. If there are other situations that require Quarkus dependencies to be present, I imagine a similar workaround would work.

[mschorsch]

@geoand Who can you ping on this topic? @Eng-Fouad ?

I'm not shure but this could be a source of hard to find bugs.

[Eng-Fouad]

@geoand Who can you ping on this topic? @Eng-Fouad ?

I'm not shure but this could be a source of hard to find bugs.

cc @aloubyansky

[aloubyansky]

Yes, I'm aware. @jskillin-idt started a zulip discussion https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/What.20code.20is.20including.20the.20-dev.20during.20a.20Gradle.20build.3F/near/529365936
I'm looking into it.

[aloubyansky]

I've got the reproducer passing with this branch https://github.com/aloubyansky/quarkus/tree/gradle-comp-variants
I'll be looking into cleaning up and finalizing the changes. I'll also look into adding the provided reproducer to our testsuite.