pnokerandClaude Code
4cb3fd6440
The dc3-db aggregate mixed two naming axes and one axis-free module:
infrastructure used dc3-db-r2dbc-{core,runtime,postgres} (with "postgres"
sitting in a layer slot), the domain adapters used dc3-db-postgres-{domain}
(no "r2dbc" at all), and tck had no axis. PostgreSQL-only and R2DBC-only
are properties of the whole aggregate (dc3-db README, docs/db-dialects.md),
so the per-module prefixes carried no discriminating information — the
65 store classes already say R2dbc in their names.
New layout, one dc3-db-{role} pattern, aligned with the common-{domain} /
center-{domain} pairs they serve:
dc3-db-r2dbc-core -> dc3-db-core
dc3-db-r2dbc-runtime -> dc3-db-runtime (absorbs the dialect)
dc3-db-r2dbc-postgres -> (merged into dc3-db-runtime)
dc3-db-postgres-auth -> dc3-db-auth
dc3-db-postgres-manager -> dc3-db-manager
dc3-db-postgres-data -> dc3-db-data
dc3-db-postgres-agentic -> dc3-db-agentic
dc3-db-tck -> unchanged
The dialect module held a single 12-line AutoConfiguration registering
StandardR2dbcDialect("postgres", ...) plus the r2dbc-postgresql driver;
both move into dc3-db-runtime (package io.github.pnoker.db.runtime.dialect,
registered in the runtime AutoConfiguration.imports, driver dependency
transferred). Its six dependents now rely on the runtime they already
pulled in. Java packages rename in step — io.github.pnoker.db.r2dbc.core
-> io.github.pnoker.db.core, io.github.pnoker.db.r2dbc.runtime ->
io.github.pnoker.db.runtime, io.github.pnoker.db.postgres.{auth,manager,
data,agentic} -> io.github.pnoker.db.{auth,manager,data,agentic} — so no
trace of the old axis survives outside git history.
Also fixes the stale module layout in docs/design/relational-r2dbc.md §6
(it still described stores living in dc3-common-*/repository, the
pre-7fde11134 arrangement) and ships migrations/02-schema-fingerprint-
resync.sql for existing volumes still carrying the pre-documentation
fingerprint marker.
Verified: full-reactor compile, dc3-db aggregate tests (-am), all six
service images rebuilt through the multi-stage Dockerfile (container
Maven package), WSL stack recreated with every center healthy, and an
end-to-end login + manager list smoke test through the gateway (JWT
cookie, offset/limit/sort paging).
Co-Authored-By: Claude Code <noreply@anthropic.com>
DC3 Coverage
dc3-coverage is a report-only Maven module. It aggregates JaCoCo execution data from the covered handwritten-code
modules and applies the repository's absolute coverage gate.
Generate and Verify the Report
From the repository root:
make coverage
Equivalent Maven command:
mvn -s .mvn/settings.xml -B -Dmaven.test.skip=false -pl dc3-coverage -am verify
Outputs:
- HTML:
dc3-coverage/target/site/jacoco-aggregate/index.html - XML:
dc3-coverage/target/site/jacoco-aggregate/jacoco.xml
Gate
The minimum line and branch ratios are configured in this module's pom.xml. The verify phase passes the aggregate XML
to scripts/check_coverage.py, which checks those absolute thresholds.
There is currently no baseline-relative regression calculation. Do not describe the build as enforcing a percentage drop against a previous commit unless such a comparison is implemented.
Use -Dcoverage.check.skip=true only for local diagnosis; do not disable the gate in normal CI or release validation.
Adding covered modules
Add a dependency in pom.xml only for a module whose handwritten classes should contribute to the aggregate. Generated
API artifacts and deployment-only wrappers should remain excluded unless the coverage policy changes deliberately.