Skip to content
Docs

Artifacts

View Markdown

This page is where to look up how a Vertique application depends on the framework:

  • The application parent: vertique-app-parent, the supported Maven boundary a generated application inherits.
  • The BOM: for an application that cannot use that parent.
  • The four starters: the coordinates that compose framework capability behind one class name each.
  • The three archetypes: the coordinates that generate a working application.
  • The module index: docs/modules.md, the canonical index for discovering every other published artifact.

It links to each of those and does not repeat their own inventories here.

The application parent

Section titled “The application parent”

dev.vertique:vertique-app-parent is the public Maven boundary a generated application inherits. ${vertiqueVersion} is the archetype’s own placeholder, substituted at generation time by the -DvertiqueVersion property (VERTIQUE_VERSION in Quickstart), so a generated project’s actual pom.xml carries the literal version in its place. This is the parent block from the REST archetype’s own template, quoted verbatim:

<parent>
    <groupId>dev.vertique</groupId>
    <artifactId>vertique-app-parent</artifactId>
    <version>${vertiqueVersion}</version>
    <relativePath/>
</parent>

Parenting to it gives an application several things. The Vertique BOM is imported into its own dependency management, so a dev.vertique dependency it declares needs no explicit version, as the REST archetype’s own generated pom.xml declares vertique-starter-rest and vertique-launcher in Quickstart. The compiler targets Java 21 (so applications run on Java 21+). Maven Compiler Plugin is already configured with the Dagger annotation processor plus the complete Vertique processor facade (vertique-codegen-all). The Maven Surefire and Failsafe plugin versions are pinned. Spotless is configured with the Palantir Java format, so ./mvnw spotless:apply formats an application’s sources without any setup of its own. Spotless is configuration only: no goal is bound to the lifecycle, so a build never fails on formatting unless the application binds it. The parent also does not bind Failsafe’s integration-test/verify goal executions, and it does not configure exec-maven-plugin or jib-maven-plugin. Each archetype’s own generated pom.xml declares all three directly, as Deployment shows for the packaging and local-run commands.

The BOM, for an application that doesn’t use the parent

Section titled “The BOM, for an application that doesn’t use the parent”

An application that must keep its own parent imports vertique-bom directly instead, following the “Custom parent: BOM plus processor facade” recipe in the packaging guide, also summarized in this repository’s own root README. The property name vertique.version matches VERTIQUE_VERSION from Quickstart, and REST APIs uses the same convention for its OpenAPI build plugin. Define that property in your own pom.xml and import the BOM with it:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>dev.vertique</groupId>
            <artifactId>vertique-bom</artifactId>
            <version>${vertique.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Importing the BOM on its own manages dependency versions only. It does not configure the compiler or the Dagger/Vertique annotation processor path the way vertique-app-parent does. See the same recipe in the packaging guide for the accompanying Maven Compiler Plugin configuration a custom-parent application still has to add itself.

Starters

Section titled “Starters”

Application model covers what each starter aggregate composes and how starters combine. This page only lists where to find each one. Every group id is dev.vertique.

Starter Depend on it when Reference
vertique-starter-core your application needs the lifecycle foundation with no HTTP, event-bus, or persistence layer module reference
vertique-starter-rest your application serves an HTTP API through JAX-RS resources module reference
vertique-starter-services your application executes typed service contracts through managed service verticles module reference
vertique-starter-postgresql your application needs PostgreSQL pooling and Flyway migration wiring, alongside an application starter, which it does not replace module reference

An application parented on vertique-app-parent (or importing vertique-bom directly) declares one or more of these with no explicit version, as Quickstart, Services, and Persistence each show.

MCP artifacts

Section titled “MCP artifacts”

MCP is composed from small artifacts and has no starter aggregate. Add only the runtime and observer capabilities the application uses. The MCP processor is part of the vertique-codegen-all facade: it activates automatically for any application that depends on vertique-codegen-all, including every application that inherits vertique-app-parent. Add vertique-codegen-mcp explicitly to the Maven Compiler Plugin’s annotationProcessorPaths only in an off-parent setup that does not depend on the facade.

For a first working composition, see Use MCP with Vertique and its public vertique-example-mcp source.

Artifact Responsibility Reference
vertique-mcp-core tool annotations plus neutral generated-runtime and lifecycle contracts module reference
vertique-mcp-server stateless Streamable HTTP transport, bounded protocol handling, authorization, validation, and dispatch module reference
vertique-codegen-mcp compile-time tool registry, invokers, schemas, and Dagger bindings; activated automatically via the vertique-codegen-all facade module reference
vertique-micrometer-mcp optional bounded-dimension MCP metrics observer module reference
vertique-opentelemetry-mcp optional MCP span enrichment and completion-scope observer module reference

The released modules document a supported-scope conformance claim for the final 2026-07-28 discovery, tool-list, and tool-call surface. Read vertique-mcp-server’s reference before choosing configuration limits or publishing application methods as remotely reachable tools.

Resilience modules

Section titled “Resilience modules”

Resilience is a separately consumable capability and is not an implicit property of every starter. Add vertique-resilience when application code declares the common annotations or uses the programmatic runtime. The REST client and Services modules depend on it transitively and enforce their supported timeout, retry, circuit-breaker, and bulkhead policies through the same runtime. JAX-RS resource methods can use the timeout annotation through the AOP path, but RestModule alone does not install that path: add ResilienceModule, ResilienceAopModule, and the generated GeneratedAopModule as described in REST APIs. Applications using the annotations also receive vertique-codegen-resilience through vertique-codegen-all; add the processor explicitly only in an off-parent setup that does not use the facade. Add the optional Micrometer adapter when resilience events should be recorded in the application’s shared registry.

Artifact Role Reference
vertique-resilience Canonical annotations, resolved declarations, runtime policies, execution budgets, and observer SPI module reference
vertique-codegen-resilience Compile-time validation for @Resilient, resilience declarations, policy names, and proxyability; included by vertique-codegen-all module reference
vertique-micrometer-resilience Optional Micrometer observer adapter; follows metrics.enabled and isolates registry failures module reference

The resilience module reference is also the source of truth for fatal Error handling: fatal values are rethrown, and they are not retried or counted as ordinary failures. The runtime accepts one consequence of Vert.x cleanup: fatal cleanup can reset accumulated closed-state breaker failures and close a half-open breaker before the same fatal value is rethrown.

Archetypes

Section titled “Archetypes”

Each archetype is the generation entry point for one of the starter combinations above. Every group id is dev.vertique, and every one generates the same way: mvn archetype:generate with the archetype’s own coordinate plus the generated project’s own groupId/artifactId/package, as Quickstart, Services, and Persistence run end to end.

Archetype Generates Reference
vertique-archetype-rest a REST API application on vertique-starter-rest Quickstart, archetype reference
vertique-archetype-services a contract-based services application on vertique-starter-services Services, archetype reference
vertique-archetype-rest-postgresql a PostgreSQL-backed REST application on vertique-starter-rest and vertique-starter-postgresql Persistence, archetype reference

Discover every artifact

Section titled “Discover every artifact”

docs/modules.md is the canonical index of every BOM-managed consumable Vertique artifact: one row per artifact, sorted by artifact id, linking directly to that artifact’s own canonical module.md reference. Every “module reference” link elsewhere on this page and throughout this corpus points at the same kind of reference. The application parent, the BOM, and the three archetypes above each have no canonical module.md of their own and are documented on this page instead. This corpus’s own pages walk specific journeys through a subset of that index. docs/modules.md is where to look up any other Vertique artifact by name.

Learn more

Section titled “Learn more”

Continue reading

Section titled “Continue reading”