Skip to main content

Quarkus and Micronaut Targets in TeaQL's Java Generator

· 3 min read
TeaQL Team
TeaQL Team
Core Team

TeaQL's generation service now advertises Quarkus and Micronaut application targets alongside Spring Boot.

The java-web-quarkus and java-web-micronaut targets are designed to place framework-specific wiring around the same generated Java domain core. This article explains that boundary and, just as importantly, how to verify the generated output.

Beyond Spring Boot​

Spring Boot, Quarkus, and Micronaut make different trade-offs around dependency injection, startup, native-image support, and runtime integration. Those differences should not require three versions of the business model.

TeaQL keeps entities, generated query APIs, expressions, checkers, and intent requirements in the domain layer. A framework target is responsible for HTTP endpoints, dependency injection, lifecycle management, and the concrete DataSource adapter.

Architecture & Dependencies​

To make this multi-framework support possible, we designed a clean separation between the domain logic and the framework-specific infrastructure. Depending on the framework you choose, your generated project will rely on a specific set of TeaQL components:

Spring Boot Architecture​

When targeting java-web-spring-boot, the architecture uses Spring's ecosystem:

  • teaql-provider-spring-jdbc: The core execution adapter that binds TeaQL's AST to Spring's NamedParameterJdbcTemplate.
  • teaql-data-service-sql: The standard SQL generation and metadata service.
  • Infrastructure: Standard Spring Boot starters for Web and JDBC, using Spring's @Configuration and @Bean lifecycle.

Quarkus Architecture​

For java-web-quarkus, the intended adapter path avoids Spring dependencies:

  • teaql-provider-jdbc: A pure JDBC provider that connects directly to any javax.sql.DataSource.
  • teaql-data-service-sql: The shared SQL runtime engine.
  • Infrastructure: The target template is designed to use Quarkus web endpoints, Agroal connection pooling, and @ApplicationScoped CDI beans for TeaQL runtime registration.

Micronaut Architecture​

For java-web-micronaut, the intended wiring follows Micronaut's bean model:

  • teaql-provider-jdbc: The same pure JDBC provider used in Quarkus.
  • teaql-data-service-sql: The shared SQL runtime engine.
  • Infrastructure: The target template is designed to use Micronaut's Netty HTTP server and @Singleton bean configuration with its JDBC data source.

Both targets are designed to use the same Java 21 java-lib-core contract. Framework adapters may differ, but domain-level APIs should be regenerated from the same reviewed model rather than copied between applications.

Generate and Verify a Target​

Targets are supplied dynamically by the generation service. Check the live catalog before copying a target name from documentation:

mvn io.teaql:teaql-maven-plugin:1.1.0:list-services
mvn io.teaql:teaql-maven-plugin:1.1.0:eval -Dinput=model

Then select one target and generate into an explicit directory:

mvn io.teaql:teaql-maven-plugin:1.1.0:generate \
  -Dservice=java-web-quarkus \
  -Dinput=model \
  -Dteaql.output=generated-quarkus

mvn io.teaql:teaql-maven-plugin:1.1.0:generate \
  -Dservice=java-web-micronaut \
  -Dinput=model \
  -Dteaql.output=generated-micronaut

Generation success and application verification are separate gates. For each output:

  1. inspect the generated manifest and framework wiring;
  2. run the generated project's tests;
  3. start the application with its configured database;
  4. execute one intent-declared query and one audited mutation;
  5. preserve the command output as verification evidence.

Verification Status​

The live catalog inspected on 2026-07-13 advertised both targets. That proves that they are discoverable through the dynamic generation API; it does not, by itself, prove that every generated workspace compiles or starts successfully. Our current compatibility matrix records verified combinations and known generator/runtime alignment gaps.

The architectural goal remains useful: framework selection belongs at the application boundary, while reviewed model metadata and generated domain APIs remain portable. We will describe a target as fully supported only after its generated workspace passes a clean build and runtime smoke test.