TCK Conformance

Ratchet defines three product/runtime conformance tiers. Each tier exposes public abstract contracts that another implementation can run. The API and Jakarta tiers require an implementation-specific runtime bridge, and the Jakarta tier also requires an Arquillian deployment. A store author does not need to satisfy Jakarta Runtime contracts to claim Store compatibility.

The separate ratchet-tck-coordinator artifact tests ClusterCoordinator implementations. It is a component-level contract suite, not another step in the Store -> API -> Jakarta tier stack.

Conformance Tiers

Tier	Module	What it proves
Store Compatible	ratchet-tck-store	The JobStore SPI implementation passes every required contract and every applicable conditional contract in the source registry. Unsupported capabilities and persistence-model-specific profiles are reported N/A.
API Compatible	ratchet-tck-api	The JobSchedulerService implementation passes the container-neutral API contracts. The adopter chooses how to bootstrap the implementation, which may still require its normal runtime environment.
Jakarta Runtime Compatible	ratchet-tck-api + ratchet-tck-jakarta	The runtime passes both API contracts and CDI injection, CDI event, and JTA transaction contracts in a live Jakarta EE container

Ratchet RI Verified is the project's own claim: the reference implementation passes all three tiers on a published matrix of servers and databases. It is not a fourth third-party tier and has no separate TCK artifact.

See Adopting the TCK for the dependencies, fixtures, runtime adapters, Arquillian packaging, report paths, and current limits of third-party self-certification.

Store Conformance Reports

The reports below are generated automatically during CI from the test runs of each store module. Each report lists every store contract with its pass/fail/missing/N/A status, grouped by Core, Behavioral, and Advanced categories. An optional capability contract is reported N/A when the store under test does not advertise that capability.

Store	Report
MySQL	MySQL Store Conformance
PostgreSQL	PostgreSQL Store Conformance
Oracle	Oracle Store Conformance
SQL Server	SQL Server Store Conformance
MongoDB	MongoDB Store Conformance

API and Jakarta Runtime Reports

Results are published for WildFly EE 10, WildFly EE 11, Payara EE 10, Payara EE 11, Open Liberty EE 10, Open Liberty EE 11, and GlassFish EE 11 across MySQL, PostgreSQL, Oracle, SQL Server, and MongoDB, and regenerated after each successful CI run on main. Payara EE 10 runs on Payara Community 6, which reached end of life with 6.2025.11. Payara EE 11 runs on Payara Community 7.

• API Conformance Matrix -- Tier 2 results across all runtimes
• Jakarta Runtime Conformance Matrix -- Tier 3 results across all runtimes

Quarkus Runtime

Ratchet also runs on Quarkus through the ratchet-quarkus extension, on the JVM and as a GraalVM native image. Quarkus is not a Jakarta EE application server, so it does not use the Arquillian container deployment that the Jakarta Runtime tier requires. Instead the extension runs the API tier contracts (ratchet-tck-api) inside a live Quarkus runtime with @QuarkusTest, which wires the engine through Quarkus CDI the same way an application does.

CI verifies the extension on every supported store:

• JVM, once per database: PostgreSQL, MySQL, Oracle, SQL Server, and MongoDB. Each cell swaps in that store's jar and a matching Testcontainers database, then runs the full extension TCK suite.
• Native image, built with GraalVM: the default SQL flavor (PostgreSQL on Hibernate ORM) and the MongoDB flavor. These exercise the native reflection surface (entities, converters, the Agroal datasource, and the MongoDB client) that a JVM run never loads.

This is part of Ratchet RI Verified, the project's own claim. It is not a separate third-party TCK artifact, and Quarkus does not appear in the Jakarta Runtime matrix above because it is not a Jakarta EE container.

Micronaut Runtime

Ratchet also runs on Micronaut 4.10 and 5 through the Micronaut integration, on the JVM and as a GraalVM native image. Like Quarkus, Micronaut is not a Jakarta EE container. An independent consumer application runs the API tier contracts (ratchet-tck-api) and the Store tier contracts (ratchet-tck-store) inside a live Micronaut application context, which wires the engine the same way an application does.

The full CI matrix tests the same Ratchet jars in two lanes, Micronaut 4.10 on Java 17 and Micronaut 5 on Java 25:

• JVM, once per lane and database: PostgreSQL, MySQL, Oracle, SQL Server, and MongoDB. Each cell runs the API and Store contracts and the consumer's process tests.
• Native image, built with GraalVM 25, once per lane and database. The process tests run the native executable and check job discovery, captured arguments, recurring work, shutdown drain, crash recovery, and SQL migration from an empty database.

This is also part of Ratchet RI Verified. It is not a separate third-party TCK artifact, and Micronaut does not appear in the Jakarta Runtime matrix above.

Running Conformance Tests Locally

Store tier:

mvn test -pl :ratchet-store-mysql -am      # generates stores/ratchet-store-mysql/target/tck-conformance-report.md
mvn test -pl :ratchet-store-postgresql -am
mvn test -pl :ratchet-store-oracle -am
mvn test -pl :ratchet-store-sqlserver -am
mvn test -pl :ratchet-store-mongodb -am

API + Jakarta Runtime tier:

mvn verify -P wildfly-managed,mysql -pl :ratchet-testsuite -am
# generates ratchet-testsuite/target/tck-api-conformance-report.md
#           ratchet-testsuite/target/tck-jakarta-conformance-report.md

Quarkus runtime (API tier, JVM): pick a store profile; each runs the extension TCK suite against a Testcontainers database for that store.

mvn verify -Pdb-postgres -pl integrations/ratchet-quarkus/integration-tests -am   # or db-mysql, db-oracle, db-sqlserver, db-mongo

Quarkus native image (needs GraalVM and Docker):

mvn verify -Pdb-postgres,native-sql -pl integrations/ratchet-quarkus/integration-tests -am   # PostgreSQL/Hibernate flavor
mvn verify -Pdb-mongo,native-mongo -pl integrations/ratchet-quarkus/integration-tests -am

Micronaut runtime (API and Store tiers): stage the Ratchet artifacts into an isolated Maven repository as the consumer harness README describes, then pick a lane and a store. Use -Pmn5 on Java 25, and add native to the profiles for a native build with GraalVM 25. On GraalVM 25, the mn4 lane also needs -Dgoogle-java-format.version=1.35.0 for its format check.

mvn verify -f integrations/ratchet-micronaut/consumer-tests/pom.xml -Dmaven.repo.local="$staged_repo" \
  -Pmn4 -Dstore=postgresql -pl :sql-consumer -am   # or mysql, oracle, sqlserver
mvn verify -f integrations/ratchet-micronaut/consumer-tests/pom.xml -Dmaven.repo.local="$staged_repo" \
  -Pmn4 -pl :mongodb-consumer -am

Implementing a Conformant Store

To claim Ratchet Store Compatible, add ratchet-tck-store as a test dependency, implement JobStoreContractFixture, and extend every required and applicable abstract contract class. The ConformanceReportExtension listener activates automatically and writes target/tck-conformance-report.md at the end of each recognized test run. Inject your store name so the report header is meaningful:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <systemPropertyVariables>
      <ratchet.tck.store.name>${project.artifactId}</ratchet.tck.store.name>
    </systemPropertyVariables>
  </configuration>
</plugin>

The complete adapter map and the distinction between MISSING and N/A are in Adopting the TCK.