Tentackle Modules
Tentackle Modules¶
Tentackle is a modular Maven reactor. Every module carries an explicit module-info.java
(JPMS) and 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.
All artifacts are on Maven Central. A BOM, a project archetype and the TestNG-support modules (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-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.
- tentackle-fx-atlanta — the Atlanta JavaFX theme.
- tentackle-project-archetype — project scaffolding (walkthrough).
- tentackle-test-pdo, tentackle-test-fx-rdc — TestNG support.
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.