Tentackle Modules
Tentackle Modules¶
Tentackle is a modular Maven reactor. Every module falls into one of three kinds:
- runtime — modules an application ships with;
- build-time — Maven plugins and code-generation support;
- common — shared by both build- and runtime.
Named modules and automatic modules¶
Twenty artifacts — every module an application ships with, plus tentackle-model — are real
JPMS modules with an explicit module-info.java:
tentackle-common, -core, -sql, -model, -session, -database, -pdo, -persistence,
-domain, -i18n, -quic, -quiche, -update, -web, -fx, -fx-rdc, -fx-atlanta, -fx-rdc-update,
-log-slf4j, -log-log4j2v and -script-jsr.
The remaining artifacts declare an Automatic-Module-Name in their JAR manifest instead. Those are
the build-time modules (the Maven plugins, tentackle-maven-support, tentackle-build-support, the
wurblets), the test-support modules (tentackle-test-pdo, tentackle-test-fx-rdc; the pure
test-scope tentackle-pdo-mock declares none, as it is only ever used on the test class path)
and the three providers whose third-party backends are themselves not
modularized (tentackle-script-groovy, tentackle-script-ruby, tentackle-fx-rdc-poi). They carry
a stable module name, so a modular application can requires them, but no compile-time module
descriptor. tentackle-bom and tentackle-project-archetype ship no code at all.
This is not a limitation of the programming model: the
Service API resolves implementations from
META-INF data written at build time, so Tentackle applications run on the module path, the class
path, or a mix of both — and the
jlink/jpackage plugin
derives the right packaging category for each artifact by itself.
All artifacts are on Maven Central. A BOM, a project archetype and the test-support modules (tentackle-pdo-mock, tentackle-test-pdo, tentackle-test-fx-rdc) round out the set but are omitted from the diagram.

The interface / implementation split¶
The defining structural idea: API modules declare interfaces, separate runtime modules implement them, and the Service API injects the implementation at runtime — so the API stays agnostic of its backend.
| Interfaces (API) | Implemented by |
|---|---|
| tentackle-session | tentackle-database |
| tentackle-pdo | tentackle-persistence (persistence) + tentackle-domain (domain) |
Runtime modules¶
| Layer | Module | Role |
|---|---|---|
| Common | tentackle-common | Build- and runtime foundation: @Analyze and other annotations, datatypes, bundle and JPMS support, the service API. |
| Common | tentackle-sql | Low-level, backend-agnostic database abstraction. |
| Core | tentackle-core | Runtime foundation: binding, validation, reflection/proxies/interceptors, tasks/daemon, preferences, plus the logging and scripting APIs. |
| Core | tentackle-i18n | Database-persisted I18N bundle support. |
| Database | tentackle-session · tentackle-database | Session handling (interfaces + implementation). |
| Application | tentackle-pdo | Persistent Domain Object interfaces: entities, aggregates, components, operations, security, number sources. |
| Application | tentackle-persistence · tentackle-domain | The persistence- and domain-side PDO implementations, injected at runtime. |
| Application | tentackle-update | Auto-update for jlink-based clients. |
| UI | tentackle-fx | JavaFX components, containers, annotations, factories and binding. |
| UI | tentackle-fx-rdc | Rich Desktop Client framework (tables, trees, forms) over PDOs and operations. |
| UI | tentackle-fx-rdc-poi · tentackle-fx-rdc-update | Pluggable Apache POI export and the client UI for tentackle-update. |
Pluggable providers (selected via the SPI): logging — tentackle-log-slf4j, tentackle-log-log4j2v, tentackle-log-log4j; scripting — tentackle-script-groovy, tentackle-script-ruby, tentackle-script-jsr (JSR-223 / GraalVM).
Build-time modules¶
| Module | Role |
|---|---|
| tentackle-maven-plugin | Main plugin: scans for @Analyze-annotated types and drives the AnalyzeHandlers that feed the ServiceFinders. |
| tentackle-sql-maven-plugin | Generates DDL and database-migration SQL from the model. |
| tentackle-check-maven-plugin | Checks resource bundles and validation annotations. |
| tentackle-i18n-maven-plugin | Syncs database-persisted I18N bundles with project resource bundles. |
| tentackle-jlink-maven-plugin | Builds self-contained images via jlink / jpackage. |
| tentackle-wizard-maven-plugin | Interactive wizard scaffolding PDO and operation sources. |
| tentackle-mcp-maven-plugin | Serves the model to coding agents over MCP, exactly as the code generators see it. |
| tentackle-build-support · tentackle-maven-support | Build helpers (Maven-independent and Maven-specific) used by the plugins. |
| tentackle-model | The model API describing entities and relationships; consumed by the wurblets, the PDO wizard and the SQL plugin. |
| tentackle-wurblets · tentackle-persistence-wurblets | Wurblets generating the PDO/operation interfaces and DTOs, and their persistence implementations. |
Further modules with documentation¶
Not part of the layered diagram, but each ships its own docs:
- tentackle-web — web tier support.
- tentackle-quic — QUIC (TRIP) transport, on the pure-Java KWIK stack.
- tentackle-quiche — the same transport on Cloudflare quiche, bound via the FFM API.
- tentackle-fx-atlanta — the Atlanta JavaFX theme.
- tentackle-project-archetype — project scaffolding (walkthrough).
- tentackle-test-pdo, tentackle-test-fx-rdc — TestNG support.
- tentackle-pdo-mock — mock PDO/operation delegates for database-less unit tests, usable by the domain- and persistence layer themselves.
Full per-module API documentation is published under the Tentackle site docs.
Related Documentation¶
- The Multi-Tier Cascade — how the same artifact runs at any tier across these modules.
- Why Tentackle Fits Technical and Scientific Applications — the design goals behind the module split.
- Correctness First — the correctness guarantees the runtime modules provide together.
- Service and Configuration API — the SPI that wires the runtime implementations into the interface modules.
- PDO / Persistent Domain Objects — the central programming model spanning the application-layer modules.