First-class Bazel support for Quarkus

[clementguillot]

Discussion: First-class Bazel support for Quarkus

TL;DR

rules_quarkus is an out-of-tree, third-party project that brings Quarkus to Bazel. It currently ships:

• A quarkus_app rule that produces a Fast-Jar (production), with optional native = True (host GraalVM or Mandrel container).
• A quarkus_dev target (auto-generated by the quarkus_app macro) that boots Dev UI, Dev Services, hot-reload, and Continuous Testing on top of Bazel-driven incremental compilation.
• A quarkus_test rule that runs @QuarkusTest JUnit 5 tests inside bazel test.

Under the hood, every entry point goes through a single Java tool (the Quarkifier (com.clementguillot.quarkifier)) that invokes Quarkus' internal build API (io.quarkus.deployment, io.quarkus.bootstrap.*) directly, bypassing Maven and Gradle resolvers entirely. The Quarkifier builds the ApplicationModel from a flat classpath, drives QuarkusBootstrap → CuratedApplication → AugmentAction, and emits the same Fast-Jar layout Quarkus produces today.

We follow Maven's DevMojo / BootstrapMavenContext patterns as closely as possible. Where Quarkus internals assume a Maven (or Gradle) project model, we either reconstruct the missing pieces by hand or work around them with reflection. The result works, but the gap between "what's possible" and "what's stable across patch versions" is wider than it should be, and the goal of this discussion is to start a conversation about narrowing it.

The two questions we'd like to put to the Quarkus team:

1. Is there appetite for a small, stable, build-tool-agnostic SPI carved out of the deployment / bootstrap APIs, that a third-party build tool can target without re-implementing slices of BootstrapMavenContext and DevMojo?
2. If yes, would the Quarkus team be open to upstreaming rules_quarkus (or at least co-maintaining a Bazel integration) once such an SPI exists?

The rest of this post explains the context, design choices, and concrete pain points that motivated these questions.

NB: This was AI-generated and reviewed by me before posting.

---

1. Why a Bazel integration matters

Bazel is the dominant build system at large polyglot shops (Google, Stripe, Uber, Pinterest, Snowflake, Twitter/X, LinkedIn, Toyota Connected, …). For these teams:

• A monorepo typically mixes Java, Kotlin, Scala, Go, Rust, TypeScript, Python, protobuf, and container images, all built by one tool.
• Hermeticity (every action declares its inputs, sandboxed execution, content-addressed caching, remote execution) is a hard requirement, not a preference.
• Dependency resolution is static: the dependency graph is materialized at workspace-load time into lock files. There is no per-build network round-trip to Maven Central. Coursier-fetched jars or rules_jvm_external-managed jars are the norm.
• The build tool is not Maven and is not Gradle. Plugging "Maven plugin + Gradle plugin" support for Quarkus into such a stack is non-trivial because the project layout (pom.xml, build.gradle, mvn/gradle invocation) is foreign to Bazel.

Until now, Quarkus has had no first-class story for these users. The closest alternatives are:

• Wrap mvn quarkus:dev and mvn package inside a genrule — gives up Bazel's caching, sandboxing, and incremental compilation, defeats the purpose of using Bazel in the first place.
• Re-implement build-time augmentation by hand — what rules_quarkus does today.

We picked the second path. This document explains the result and the trade-offs.

---

2. What does "Bazel-native" mean here?

For context: in Bazel, a "rule" is a pure Starlark function that takes inputs (sources, dependencies, attributes) and declares outputs and actions. Each action is a sandboxed subprocess (ctx.actions.run) with a fully declared input set, run by Bazel inside a hermetic sandbox, fingerprinted, and cached locally and remotely. There is no "build lifecycle" the way Maven has one — there is a build graph.

A Bazel-native Quarkus integration therefore must:

• Express the Quarkus augmentation step as a ctx.actions.run action with a fully declared classpath input (every jar listed, every source file listed, no implicit lookups).
• Avoid touching anything that isn't declared: no ~/.m2, no ~/.gradle/caches, no walking parent directories looking for a pom.xml. The action runs inside /tmp/bazel-sandbox/....
• Be reproducible byte-for-byte across machines (modulo timestamps), so remote cache hits are real cache hits.
• Co-exist with rules_java, rules_jvm_external, rules_kotlin, etc., without imposing its own Java compilation rule on the user. Users keep their java_library targets and their maven_install repos; quarkus_app just consumes them.

The reference implementation is in quarkifier/ (Java tool) and quarkus/ (Starlark rules). See docs/architecture.md and docs/quarkifier.md for the full pipeline.

---

3. The three big differences from Maven & Gradle

3.1 Dependency resolution happens outside the build action

In Maven, when quarkus:dev or quarkus:build runs, the plugin has full access to a live MavenProject and can call into the Maven resolver any time it wants (and it does — BootstrapMavenContext re-resolves the project model, walks the reactor, talks to the local repository). Gradle is similar: the plugin has a Project handle and can resolve configurations on demand.

In Bazel, this is forbidden by design. The augmentation action runs in a sandbox with only the inputs Bazel declared. There is no live project model, no reactor, no resolver to call. Dependencies have already been resolved at workspace-load time (when rules_jvm_external's maven_install extension ran), captured in a maven_install.json lock file, and exposed as a flat set of jar files.

The Quarkifier therefore:

• Receives a flat classpath (list of jars) as a CLI argument.
• Scans each jar's META-INF/quarkus-extension.properties to discover extensions.
• Reconstructs ApplicationModel manually by walking the classpath, parsing GAV from filenames (MavenCoordinateParser), and feeding ApplicationModelBuilder.handleExtensionProperties() for each extension.
• Resolves the -deployment jars from a separate, pre-fetched classpath that the module extension downloads at workspace-load time via Coursier (see docs/architecture.md → "Module Extension System").

There is no live network call during build. There is no mvn dependency:tree. The ApplicationModel is built from path strings and JarFile reads, nothing else.

3.2 The "project model" doesn't exist in the Maven sense

Quarkus internals carry a strong assumption that somewhere there is a WorkspaceModule, a MavenContext, a parent POM, a reactor. Many code paths reach for it. A few examples we've hit:

• BootstrapAppModelFactory.resolveAppModel() in test mode falls through to loadWorkspace() → createBootstrapMavenContext() when the quarkus-internal-test.serialized-app-model.path system property is unset. In Bazel, those resolver classes are not (and must not be) on the classpath.
• ApplicationModel.asMap() (the JSON serializer used in 3.31+) calls getPlatforms().asMap() without a null check. Bypassing Maven/Gradle means platformImports is never populated, so we set an empty PlatformImportsImpl() purely to dodge an NPE.
• handleExtensionProperties() builds GACT keys with empty type, but our model entries have type = "jar". The result is that the CLASSLOADER_RUNNER_PARENT_FIRST flag is never set, so we have to monkey-patch each artifact by artifactId after the fact.
• The Dev UI Extensions panel is wired to a RemoteRepository (org.eclipse.aether.repository.RemoteRepository) instance that the Maven resolver supplies. Our ApplicationModel doesn't have one, and the panel currently throws ClassCastException across classloaders. We don't have a clean fix.

Every one of these is a small leak of "this code assumes Maven (or Gradle) is what called it" into what should be a build-tool-agnostic build API.

3.3 Augmentation runs in a Bazel action, not as a build lifecycle

In Maven, augmentation is a phase. The plugin has time to set things up, resolve, augment, package, repeat. In Bazel, augmentation is a single subprocess invocation that produces a Fast-Jar directory in its declared output path and exits. The orchestration (caching, sandboxing, retries, remote execution, etc.) is Bazel's job, not Quarkus'.

This is a feature, not a bug — it's the whole reason to do this work. But it does mean:

• The Quarkifier has to be fully CLI-driven, no environment lookups (QuarkifierConfig.parse() with property-based round-trip tests).
• Augmentation must be deterministic: same classpath → same Fast-Jar (modulo timestamps). We have to be careful about iteration order; depsets are unordered in Starlark and Map.keySet() is unordered in Java.
• The output post-processing (FastJarAssembler.assemble()) is non-trivial because Quarkus places jars under lib/main/ using the original classpath filenames (including Bazel's processed_ prefixes), and we have to rename, classify boot vs main, dedupe, and regenerate quarkus-application.dat.

---

4. Following the Maven implementation

When in doubt, we copy quarkus-maven-plugin. Both because Quarkus was originally Maven-first and because the Maven sources are the only thing we can stare at to understand the intended classloader / lifecycle / serialization contracts.

Concrete examples:

Maven reference	What we copy	Where
DevMojo.createDevJar()	Building a thin "dev jar" with a manifest Class-Path of file:/// URIs that points to the core deployment infrastructure and parent-first artifacts; everything else flows through the augment classloader from the ApplicationModel.	DevModeLauncher.createDevJar()
DevMojo subprocess launch	Spawning a separate JVM for dev mode (java -jar dev.jar) so the parent classloader stays minimal. IsolatedDevModeMain runs inside a clean augment classloader.	DevModeLauncher.launch()
BootstrapMavenContext.loadWorkspace()	We deliberately don't call it. Instead, we build ApplicationModel from the classpath and serialize it to the path Quarkus reads from quarkus-internal.serialized-app-model.path (and quarkus-internal-test.serialized-app-model.path for continuous testing).	QuarkusAppModelBuilder, DevModeLauncher
BootstrapAppModelFactory test-mode short-circuit (-Dquarkus-internal-test.serialized-app-model.path)	We pre-serialize a test ApplicationModel and pass that property to the dev mode child JVM so that clicking "Start Continuous Testing" doesn't fall through to createBootstrapMavenContext().	DevModeLauncher (see §6.4)
Maven's automatic resolution of conditional-dev-dependencies	We resolve these explicitly in our module extension (extra Coursier fetches for quarkus-devui, quarkus-devui-deployment, quarkus-devui-spi, {extension}-dev, etc.) because nothing on the Bazel side will discover them transitively.	quarkus/extensions.bzl, see docs/dev-mode.md → "Conditional Dev Dependencies"
Maven's application root semantics	We treat every local workspace jar as an application root (PathList-with-multiple-entries to QuarkusBootstrap.setApplicationRoot()), because Bazel's depset gives no guaranteed first jar. Without this, OpenAPI / @Path discovery breaks for multi-module projects.	AugmentationExecutor (see §6.5)
Maven's parent-first / runtime / deployment classloader hierarchy	Replicated in QuarkusAppModelBuilder — same parent-first list (bootstrap, core, logging, Jakarta APIs), same SmallRye Config exception (must not be parent-first because CDI beans inside it would VerifyError), same "mark -dev and -spi runtime jars" rule.	dev-mode.md → "Parent-First Artifacts"

The takeaway: if Maven does it, we do the same thing. Where we differ, it's because we have to (no Maven context available), not because we wanted to.

---

5. The core difficulty: Quarkifier ↔ Quarkus version coupling

This is the single biggest design problem and the reason this discussion exists.

5.1 The problem

The Quarkifier links against Quarkus' deployment APIs:

• io.quarkus.deployment.* (AugmentAction, IsolatedDevModeMain, DevModeMain, ...)
• io.quarkus.bootstrap.* (QuarkusBootstrap, CuratedApplication, ApplicationModelBuilder, BootstrapUtils, ...)
• io.quarkus.bootstrap.app.ApplicationModel, ApplicationModelSerializer
• io.quarkus.bootstrap.devmode.DevModeContext

None of these are documented public APIs. They are deployment-internal. Their signatures, method bodies, and bytecode-level expectations change between Quarkus releases — sometimes between minor versions, sometimes between patches.

Three concrete examples we've already hit:

1. ApplicationModelSerializer format flip (3.31) — In 3.27, BootstrapUtils.serializeAppModel() used Java Object Serialization. From 3.31+, ApplicationModelSerializer.serialize() emits JSON. The wire format is incompatible; the Quarkifier needs version-specific code to pick the right serializer. We dispatch via a small AppModelSerializerStrategy SPI with one implementation per minor (src/main/java_3_27/AppModelSerializerImpl.java, src/main/java_3_33/AppModelSerializerImpl.java).

2. PlatformImports.asMap() NPE (3.31+) — JSON serialization started calling getPlatforms().asMap(). Because we bypass Maven, platformImports is null. We patched around it with an empty PlatformImportsImpl(). This is a workaround that wouldn't be needed if the build API tolerated a missing platform model.

3. GACT key mismatch in handleExtensionProperties() — This was true in 3.20 and was still true in 3.33. It silently breaks the CLASSLOADER_RUNNER_PARENT_FIRST flag and we have to monkey-patch.

The implication: a Quarkifier compiled against quarkus-core-deployment:3.33.2 is not guaranteed to produce bytecode that runs against 3.33.1 runtime jars at the user's site. The augmentation step may call methods that exist in 3.33.2 but not 3.33.1, or rely on a field initializer that changed. Quarkus generates bytecode during augmentation — that bytecode references symbols, and symbols move.

5.2 What we do today

We initially keyed on minor versions, on the assumption that "API differences happen at the minor boundary". This turned out to be too optimistic — patches do break things — so the current implementation keys on the full patch version:

• SUPPORTED_VERSIONS = { "3.27.4": ..., "3.33.2": ... } — a finite, enumerated set in quarkus/private/versions.bzl.
• One maven.install(name = "maven_3_33_2", ...) per supported patch in our root MODULE.bazel, with its own lock file (maven_install_3_33_2.json).
• One quarkifier_targets("3_33_2", "@maven_3_33_2", minor = "3_33") call in quarkifier/BUILD.bazel.
• One pre-built deploy jar per patch version, published as a GitHub release asset (quarkifier-3.33.2-v0.6.0.jar).
• The module extension validates the user's quarkus_version with exact string equality against SUPPORTED_VERSIONS. No fallback. If the user says 3.33.3 and we only ship 3.33.2, the build fails loudly with a clear error.

The version-specific source directory (src/main/java_3_33/) is still keyed by minor, because that's where the SPI-level differences live; the patch granularity exists purely to guarantee bytecode compatibility.

5.3 What this costs

• Release cadence is forced to track Quarkus. Every Quarkus patch release potentially needs a new rules_quarkus release with an added entry in SUPPORTED_VERSIONS and a new pre-built deploy jar. There is no way for a user to use a Quarkus version we haven't explicitly enumerated.
• Cold-start friction for users. A user who upgrades Quarkus from 3.33.2 to 3.33.3 cannot do it until we cut a release. Maven and Gradle users just change the version string and go.
• Maintenance burden grows linearly. Two LTS lines today (3.27.4, 3.33.2) is manageable. Five would already be uncomfortable. Twenty (one for every patch ever released) is impossible. We are effectively betting that the LTS strategy keeps the support matrix small.
• Release artifact storage. Each deploy jar is ~15–20 MB. Per release × per supported version × multiple architectures = real bytes in GitHub releases.

5.4 What would help, from the Quarkus side

Any of the following, in roughly increasing order of ambition, would meaningfully reduce the version-coupling pain. We're not asking for all of them — we're asking to discuss which (if any) are feasible:

1. Document the deployment/bootstrap API surface that third-party build tools depend on, and treat that documented surface as @Experimental with explicit breaking-change notes per release. Today the deployment API is implicitly internal; in practice every alternative build tool integration has to either pin to a version or vendor the API.
2. A small, stable build-tool-agnostic SPI for the few touchpoints we actually need:
   • Construct an ApplicationModel from a flat list of (GAV, jarPath, parentFirst?, runtime?, ...) tuples without invoking any resolver.
   • Serialize / deserialize ApplicationModel with a stable wire format.
   • Drive AugmentAction.createInitialRuntimeApplication() and IsolatedDevModeMain with an externally-provided ApplicationModel, never falling through to BootstrapMavenContext.
   • Hot-reload: provide RuntimeUpdatesProcessor with a writable classesPath and trust the caller to keep it fresh; no internal QuarkusCompiler.
3. Inversion-of-control hooks so that callers can plug in their own compiler (Bazel, Buck, sbt, …) for hot-reload without Quarkus trying to invoke javac via CompilationProvider ServiceLoader.
4. Pluggable platform-imports resolution, so asMap() never NPEs when platformImports isn't set, and the JSON serializer tolerates a minimal model.

We are happy to do the implementation work; what we don't have is upstream-level alignment on the SPI shape.

---

6. Why we think this is worth a conversation now

The project is at a point where:

• It works. Two LTS versions supported (3.27.4, 3.33.2). Production Fast-Jar, dev mode with Dev UI + hot-reload + Continuous Testing, @QuarkusTest, native image (host + container). E2E smoke tests pass on Bazel 7 / 8 / 9.
• It's used. The repo gets external interest. Whether it's seven users or seventy is unclear, but the issues we get are real.
• The cost of carrying it out-of-tree is non-trivial. Every Quarkus patch release potentially needs a rules_quarkus patch release. Every Quarkus internal refactor potentially breaks us. We have no early warning system — we find out at release time.
• A modest amount of upstream support would change the math. A documented SPI, even an @Experimental one, would let us drop the patch-version pinning and ride minor versions; an inversion-of-control hook for hot-reload compilation would let us delete BazelFileWatcher; explicit conditional-dev-dependencies indexing would let us delete a hand-maintained allowlist.

We are not asking the Quarkus team to take ownership of Bazel. We are asking whether there's appetite for the small, focused changes that would make any non-Maven, non-Gradle build tool a less second-class citizen — and whether rules_quarkus could be the test case that drives those changes.

If yes:

• We're happy to open targeted issues for each of section 6, with reproducers.
• We're happy to contribute patches against Quarkus core for the SPI work, with rules_quarkus as the integration test consumer.
• We're open to discussing whether rules_quarkus should eventually live under quarkusio/.

If the answer is "Quarkus is Maven-and-Gradle-first and intends to stay that way" — that's also valuable to know. It tells us we should keep the project as a community-maintained third-party module and stop hoping for upstream alignment.

Either way, we'd appreciate a conversation.

[cescoffier]

Very interesting, thanks. @aloubyansky, @gsmet, @geoand what do you think? Let's be frank: my only experience with Bazel is building true distroless containers... (so, very limited)

[geoand]

If all that is needed from us is:

Is there appetite for a small, stable, build-tool-agnostic SPI carved out of the deployment / bootstrap APIs, that a third-party build tool can target without re-implementing slices of BootstrapMavenContext and DevMojo?

then it might be doable. But there is only person that can give a proper answer to this and that is @aloubyansky

[Ladicek]

This is an amazing text! I have no answers for you, as I don't really work on the build system, but I know one thing that is probably interesting for you: Quarkus builds are currently not reproducible. We're working on fixing that (CC @reaver585), but it's gonna take a while.

[maxandersen]

hi @clementguillot - i think we met at Devoxx France? good write and up looks awesome.

I'm +1 on the idea behind this and on first read it looks to overlap with similar needs jbang (another non-first-class-but-working "builder") has.

unfortunately i'm on PTO the next week so I'll be delayed in following up in more detail.

btw. I see #11305 has some work too - not sure if you have already compared @kinhluan's approach?

[kinhluan]

thanks @maxandersen,

https://github.com/kinhluan/rules_quarkus is the public extract of the same idea Clement described: a small Bazel-run JVM tool that builds an ApplicationModel from a declared classpath and calls QuarkusBootstrap.setExistingModel(...) - no Maven/Aether resolver in the action

we use this path in a production monorepo, pinned to Quarkus 3.20.1, for Fast-Jar / Mode.PROD only (no quarkus_dev / @QuarkusTest yet)

the hard part for us is that deployment/bootstrap still assume a Maven-shaped world (deployment artifacts pull Maven/Sisu; classloader / createAugmentor() needs workarounds); we stay on 3.20.1 rather than riding newer Quarkus lines

a documented, build-tool-agnostic SPI - flat classpath → ApplicationModel → augment, without BootstrapMavenContext — would help a lot; happy to stay community-side on Bazel

[aloubyansky]

Thanks for sharing and all the efforts on the Bazel front. That's definitely great to know.

Is there appetite for a small, stable, build-tool-agnostic SPI carved out of the deployment / bootstrap APIs, that a third-party build tool can target without re-implementing slices of BootstrapMavenContext and DevMojo?

Sure. I think this kind of refactoring will be for everyone's benefit.

If yes, would the Quarkus team be open to upstreaming rules_quarkus (or at least co-maintaining a Bazel integration) once such an SPI exists?

I'd hope we'd collaborate but you guys would keep driving it on the Bazel side.

A few other remarks.

Conceptually, the Gradle integration is closer to what you describe. For example, most of the dependency resolutions happen in project configuration phase and not during a task execution. See https://quarkus.io/guides/gradle-tooling#gradle-configuration-cache for the configuration cache compatible tasks, it covers all launch modes: prod, test and dev.
The Gradle integration also doesn't use any of the Maven-related classes you referenced either, so they are not required. It's not like you can re-use Gradle integration-related classes either, unfortunately.
There are some shared code paths between Maven and Gradle integration related to test app model loading (which Gradle works around with a system property) and launching an app from an IDE. There are also some limitations in project generation and updates, atm.

The idea of delegating application rebuilding to Bazel in dev mode, for example, is a good one. We were hoping for the same in case of Gradle, with its support for incremental builds and even an API to trigger those but, unfortunately, in practice, it appeared to be significantly slower than the current Quarkus impl, so it hasn't happened yet. The general idea makes sense though for both Gradle and Bazel.

I haven't looked at your implementation, but dependency resolution is tricky subject and it's something that needs to be done right. I have some concerns based on the description.

In any case, let's continue the discussion. If that makes sense, perhaps it could also help, if you could present the topic on one the community meetings? WDYT @cescoffier ?

[clementguillot]

Thank you, everyone, for your valuable feedback!

@cescoffier Funny coincidence: distroless images are already used as the base images for OCI builds in the examples.

@Ladicek Interesting! Is there an issue or another place where I can follow your work?

@maxandersen Yes, we met at Devoxx France 😃 So sad, I missed your talk. It took me some time to get from our conversation to this discussion, but at the time, some core features were still missing.

I think @kinhluan and I use a similar approach: we both introduce a new JVM-based CLI application, managed by Bazel, that calls io.quarkus.bootstrap.app.QuarkusBootstrap with everything it needs to create a Fast JAR.

My implementation may differ in terms of the Starlark code and the Bazel API exposed to end users (DX closer to Maven/Gradle).

@aloubyansky Thank you very much for your detailed answer! There are many points I’ll dig into and incorporate into upcoming developments.

Maven was my “north star” because Quarkus itself is built with Maven. That bias may have been a mistake, so I’ll take a closer look at the Gradle plugin sources, which I had deliberately omitted until now.

Regarding dependency resolution, TBH, I also have concerns about my current implementation. I think I lack experience and knowledge in this area, and there is room for improvement and stabilization. That is also one of the motivations behind this discussion.

I’d be very happy to present the topic at a community meeting and continue the discussion if everyone agrees that it would be useful.

[geoand]

I’d be very happy to present the topic at a community meeting and continue the discussion if everyone agrees that it would be useful.

I think that would be great!

[Ladicek]

@Ladicek Interesting! Is there an issue or another place where I can follow your work?

We don't have a place you could track, alas, but you can follow the PRs by @reaver585: https://github.com/quarkusio/quarkus/pulls?q=is%3Apr+author%3Areaver585

[clementguillot]

A quick update on the project:

• Following our recent discussion, @aloubyansky, I have significantly refactored dependency resolution during the augmentation phase. Here is the related issue, which also documents the changes that have been made. At this point, only one hardcoded exclusion remains: io.smallrye.config:smallrye-config, because it contains CDI beans and causes a VerifyError when a bean class is loaded from the parent classloader. I hope I'm moving in a better direction now!
• I also recently added Quarkus extension support. This includes a quarkus_extension_runtime(..) API to build and resolve Quarkus extensions locally. Fun fact: I initially used Gradle for the sample application, but ended up switching to Maven because I could not add a link to the extension card in Dev UI. It works like a charm with Maven and Bazel. I do not yet know whether this is an issue in my own build.gradle configuration or in the Gradle plugin, but I am still investigating.
• I also refactored and cleaned up both the Java and Starlark codebases.

Next step is to add way more e2e/smoke tests to prevent from regressions.

[aloubyansky]

Sounds great @clementguillot. Thanks for the update.

[cescoffier]

@clementguillot, would you be interested in discussing your project during one of the community calls (September-ish)? If so, ping me on zulip or email.

[cescoffier]

This will be the topic of the Quarkus community call on September 1st.

[snazy]

I'm currently working on the Quarkus Gradle plugin and during that work that touched quarkus-dev/remove-dev/continuous-testing it became obvious that build-tool agnostic helper functionality was needed. I already have some changes to quarkus-core-deployment for this scenario (although the quarkus-continuous testing work isn't finished yet - but quarkus-dev + quarkus-remote-dev already work).
Would this help you guys with the Bazel work?

[clementguillot]

This is great to see! The boundary you're drawing (build tool owns compilation/resources/packaging, Quarkus owns dev-mode runtime behavior) is exactly what rules_quarkus needs.

Today we implement that handoff ad hoc: a file watcher triggers bazel build, and we sync class outputs into a mutable directory that RuntimeUpdatesProcessor watches.
A Quarkus-owned contract with explicit coalescing/staleness semantics is a much better place for that logic, and Bazel's discrete, sequenced builds map naturally onto BuildOutputChangesPolicy's sequence model.

I'd be happy to test the API as a second (non-Gradle) consumer and report back.

A few questions from our experience trying to make continuous testing work under Bazel (clementguillot/rules_quarkus#61, clementguillot/rules_quarkus#62):

1. Test outputs: BuildOutputChangesPolicy currently coalesces main classes/resources only. Do you plan a TEST_CLASSES/TEST_RESOURCES category that feeds TestSupport.runTests(ClassScanResult), so externally compiled test classes can trigger CT's affected-test selection? For us that's the missing piece for CT hot-reload.
2. Process boundary: our build-tool side lives in a separate JVM from dev mode. Is the delivery path (Sender) intended to be same-JVM only, or is a local transport planned (the remote-dev protocol suggests one exists for the remote case)?
3. Test ApplicationModel contract: we got CT partially working by pre-serializing a test model via SERIALIZED_TEST_APP_MODEL (the Gradle mechanism), but discovery then failed because FacadeClassLoader couldn't be loaded from the deployment classloader, and the fallback at JunitTestRunner is a silent debug-level log. Would you be open to (a) documenting what a hand-built test model must contain (quarkus-junit5 placement, parent-first flags for JUnit platform artifacts), and (b) making that fallback warn loudly when @QuarkusTest classes were discovered but can't be loaded?
   Jar-based test outputs: JunitTestRunner.discoverTestClasses() requires a directory (Files.walk); Bazel produces jars, so we extract to a temp dir. Would jar support be in scope for this effort?
4. Jar-based test outputs: JunitTestRunner.discoverTestClasses() requires a directory (Files.walk); Bazel produces jars, so we extract to a temp dir. Would jar support be in scope for this effort?

And last but not least, which version of Quarkus are you targeting? I guess I won't be out before next major 4.x?

[snazy]

1. Test outputs

Yep! That's currently the biggest remaining work item: continuous builds w/ tests. That's actually the reason why I haven't opened the PR earlier - I wanted to push it with that. I can add that in a 2nd PR or amend the current one - I'm open to either approach.

2. Process boundary

Looks like Gradle and Bazel share very common concepts here. The Quarkus process is technically running in a separate JVM for the quarkus-dev case - this is where the transport comes in via TCP with minimalistic authN.

3. Test ApplicationModel contract

Sure, I can document what I find and share it with you. I already have a lot of docs that I created during the work - currently, it may appear as "just a ton of docs". I want to get targeted docs out of that. I've also got a synergies doc that mentions exactly the application model (at the end).

4. Jar-based test ouptputs

Gradle would also produce a classes directory. A jar seems to require at least a change to JunitTestRunner.discoverTestClasses.

Quarkus version

Yes, target is Quarkus 4.

[snazy]

Small clarification on the test ApplicationModel part: yes, improving the diagnostics around the JunitTestRunner fallback also sounds useful to me, not just documenting the expected shape.

[snazy]

Following up on the external build-output part of this discussion, the currently open PRs that may be relevant are:

• #56139: Add external build-tool dev helpers to core deployment adds the output-change model and policy, package snapshots and diffs, and a remote-dev package client. This is the main direct reuse point for another build tool that owns compilation.
• #56137: Make remote-dev session updates consistent hardens the shared remote-dev session handling used by clients that deliver updates to a running Quarkus process.
• #56142: Add Gradle bootstrap support for new plugins and external build tools adds a Gradle application-model sidecar and validation. It is Gradle-specific rather than a Bazel API, but may be useful context for the application-model boundary.

The next direct follow-up is the local TCP transport and dev-mode integration;
I plan to open it after #56139 is merged. Continuous-testing support will follow after that.

If this maps to how rules_quarkus moves build outputs into a running Quarkus process, feedback while this is under review would be useful.

[kinhluan]

We maintain our own Bazel rules for Quarkus; https://github.com/kinhluan/rules_quarkus

Interestingly we converged on a different set of internals. We do not touch BootstrapMavenContext or DevMojo at all — Bazel already resolved the classpath, so we build the ApplicationModel by hand instead:

io.quarkus.bootstrap.app.QuarkusBootstrap
io.quarkus.bootstrap.app.CuratedApplication
io.quarkus.bootstrap.app.AugmentAction
io.quarkus.bootstrap.model.ApplicationModelBuilder
io.quarkus.maven.dependency.ResolvedDependencyBuilder
io.quarkus.maven.dependency.DependencyFlags

Flow

pre-resolved Bazel graph
  → hand-built ApplicationModel
  → QuarkusBootstrap.setExistingModel(...)
  → bootstrap()
  → createAugmentor()
  → createProductionApplication()

Bazel owns dependency resolution, so the essential contract for us is: here is the complete resolved graph; do not resolve anything.
This became painful when enabling a pinned dependency lockfile. One stray transitive dependency introduced an older Quarkus bootstrap artifact, causing augmentation to fail with:

NoSuchMethodException:
io.quarkus.runner.bootstrap.AugmentActionImpl.<init>(
    io.quarkus.bootstrap.app.CuratedApplication
)

Quarkus bootstrap components from one version expected a constructor that was absent from the older artifact. We fixed the problem by auditing the dependency graph and removing the offending artifact, so the build is pinned and green today.
The failure mode is the important part: version skew across tightly coupled bootstrap components can prevent every affected service from building, with no documented compatibility boundary to warn an external build-system integration about the change.
The capability that would help us most is a supported SPI for supplying a fully pre-resolved ApplicationModel: “Here is the graph; resolve nothing.”

Today, ApplicationModelBuilder, ResolvedDependencyBuilder, DependencyFlags, and QuarkusBootstrap.setExistingModel(...) provide that capability, but not as a clearly documented, compatibility-guaranteed contract for third-party build systems. Stabilizing that boundary would remove most of our reverse engineering and turn Quarkus upgrades into routine dependency bumps rather than compatibility gambles.

A smaller second capability concerns CDI discovery for artifacts without meaningful Maven coordinates. Bazel-produced JARs typically have neither a Jandex index nor real GAV coordinates, and they may not contain META-INF/beans.xml.
We currently synthesize coordinates and supply quarkus.index-dependency.* properties before augmentation so that Quarkus indexes those artifacts. It works, but it relies on an undocumented mapping between synthetic coordinates, the application model, and bean discovery.