Vidocq Projects

All fifteen Vidocq sub-projects, their scope, and how they fit together.

Vidocq is a workspace of fifteen independent Maven projects. Each one implements exactly one Jakarta or MicroProfile specification — or one foundational concern — and publishes its own artifact to Maven Central on its own schedule.

The dependency graph is strictly layered: foundational bricks have no dependency on each other; Jakarta layers compose bricks; MicroProfile layers sit on top.

Foundational Bricks

These four modules have zero inter-dependencies and carry no external runtime libraries. They are the stable base everything else builds on.

chappe — HTTP Server

Pure Java 25 HTTP/1.1 and HTTP/2 transport layer, with first-class WebSocket (RFC 6455) and gRPC transport (core framing over HTTP/2). HTTP/3 is on the roadmap, pending the JDK QUIC stack. Handles connections, request parsing, and response serialisation with no third-party I/O framework.

Sustains 100k req/s with a p99 below 3 ms on the project’s reference harness — a deliberate ceiling of the pure one-virtual-thread-per-connection model, matching Jetty-level latency at a fraction of the idle memory footprint.

vauban — CDI Container

CDI 4.1 Lite container, fully JPMS-native. Uses the Class-File API and APT processors to generate bean metadata at compile time — no runtime scanning, no reflection.

champollion — JSON & Protobuf Processing

Jakarta JSON-P 2.1 and JSON-B 3.0 implementation. Produces JSON-B adapters and serialisers statically at build time. Also provides Protocol Buffers support, generating message codecs at compile time — the serialisation backend for `chappe’s gRPC transport, with no external protobuf runtime.

ravel — Configuration

MicroProfile Config 3.1 implementation. Sources: environment variables, system properties, and META-INF/microprofile-config.properties.

Jakarta EE Layer

foy — Jakarta Servlet 6.1

Note

Development in progress. The Servlet layer is actively being built out and is not yet feature-complete.

Servlet container bridging chappe for transport and vauban for CDI integration.

cassini — Jakarta REST 4.0

JAX-RS implementation. Resource scanning and provider registration are handled at compile time via APT, keeping startup time flat regardless of application size.

MicroProfile Layer

heisenberg — Fault Tolerance 4.1

@Retry, @CircuitBreaker, @Bulkhead, @Timeout, and @Fallback over virtual threads. No thread-pool per policy; each interceptor submits to the shared virtual-thread executor.

cervantes — JWT 2.1

MicroProfile JWT: bearer token verification and JsonWebToken injection. Uses champollion for JSON parsing; no third-party JWT library.

cyrano — Rest Client 4.0

Typed REST client generated at compile time from @RegisterRestClient interfaces. Built on cassini and chappe; no dynamic proxies at runtime.

dirac — Metrics 5.1.1

MicroProfile Metrics: counters, gauges, timers, and histograms exposed over a /metrics endpoint.

grimm — OpenAPI 4.1

MicroProfile OpenAPI: generates the OpenAPI document from JAX-RS resources during the build via APT, then serves it statically at runtime.

humboldt — Telemetry 2.1

MicroProfile Telemetry: distributed tracing, metrics, and logs through the OpenTelemetry SDK.

knock — Health 4.0

MicroProfile Health: liveness and readiness probes at /health/live and /health/ready.

Persistence and Transactions

mansart — Jakarta Data 1.0 + Transactions 2.0 + JDBC

Repository pattern and transaction management with a built-in JDBC connection pool. Two database dialects are supported out of the box: H2 and PostgreSQL. Jakarta Persistence 3.2 support is planned for a future milestone.

The H2 integration also showcases Vidocq’s JAR-enrichment capability: a dedicated H2 extension repackages the upstream H2 driver as a proper JPMS module — adding a module-info and clean exports to a library that ships only as a classpath JAR — so it fits the strict module graph without --add-opens or automatic-module fallbacks.

Orchestrator

vidocq — Vidocq-MPS

Runtime orchestrator and extension SPI. Inspired by the Quarkus extension model: extensions declare their dependencies, contribute configuration, and wire the other bricks together at startup.

Dependency Graph

FoundationJakarta EEMicroProfilePersistenceOrchestrator«HTTP/1.1 · H2 · WS · gRPC»chappe«CDI 4.1 Lite»vauban«JSON-P · JSON-B · Protobuf»champollion«Config 3.1»ravel«Servlet 6.1»foy«REST 4.0»cassini«Fault Tolerance 4.1»heisenberg«JWT 2.1»cervantes«Rest Client 4.0»cyrano«Metrics 5.1»dirac«OpenAPI 4.1»grimm«Telemetry 2.1»humboldt«Health 4.0»knock«Data 1.0 · Tx 2.0»mansart«Vidocq-MPS»vidocq