What is the Axelix Build Plugin?

The Axelix build plugin is a small Gradle or Maven plugin you apply to every service you want Axelix to manage. It runs at build time and writes a `META-INF/axelix-info.properties` file into your application's artifact. That file carries the identity Master uses to tell one application apart from another.

It is the companion to the Axelix Spring Boot Starter: the starter is the runtime component that talks to Master, and the build plugin is the build-time component that gives the starter something to report. Both are required — a service with the starter but without the plugin cannot register.

What it produces

At build time the plugin generates META-INF/axelix-info.properties and records:

Build coordinates — groupId, artifactId, and version. These are the identity Master keys everything on.
A build timestamp — when the artifact was assembled.
Git metadata — when the build runs inside a Git repository, the current commit, branch, and author.

At runtime the starter reads this file and sends the coordinates to Master as part of the instance's registration metadata.

Dependency SBOM (Gradle)

UpcomingAvailable in an upcoming minor release

On top of the identity file, the Gradle plugin generates a dependency SBOM — a CycloneDX 1.6 JSON document describing the application's runtime dependency graph. It is packaged into the artifact at META-INF/axelix/dependencies.cdx.json, next to the build info. Master reads it to see which libraries the application actually ships and how each one ended up on the classpath.

The document is produced by the generateAxelixDependenciesSbom task. You are not supposed to run it by hand: jar, bootJar, and processResources all depend on it, so a regular build packages the SBOM automatically, and test or bootRun see it on the classpath too. The task re-runs only when the resolved dependency graph changes.

The SBOM describes the fully resolved runtimeClasspath — the exact set of libraries that ships, not the versions you declared:

Resolved versions only. When two dependencies ask for different versions of the same library, the document records the version Gradle selected. Dynamic declarations such as 2.0.+ appear as the concrete version they resolved to, and versions pinned by a BOM (platform(...)) appear as pinned.
Runtime scope. runtimeOnly dependencies are included. compileOnly dependencies never ship, so they are excluded.
Resolution paths. Every library carries dependsOn edges to the libraries it pulled in, so the chain from your application down to each transitive dependency is preserved.
Your own modules stay out. In a multi-project build, subprojects the application depends on are not listed as libraries — the libraries they pull in are attributed directly to the application. Each project that applies the plugin gets its own SBOM, describing its own runtime classpath.

Like the rest of the plugin, the SBOM needs no configuration. It is currently generated by the Gradle plugin only; the Maven plugin does not produce it yet.

The generated artifacts are internal

Everything the build plugin writes into your artifact — META-INF/axelix-info.properties, the dependency SBOM, and any file added in future releases — exists for a single consumer: the Axelix Spring Boot Starter. The starter reads these files and reports their content to Master. That is the whole contract.

Be careful if you rely on generated artifacts

Treat the generated files as Axelix internals. Their names, locations, format, and content may change in a minor or major release without much notice, and such a change is not considered breaking. If your own tooling parses axelix-info.properties or dependencies.cdx.json out of the artifact, expect it to break on upgrade.

This applies to the dependency SBOM in particular. It uses the standard CycloneDX format, but it is generated for Master's needs — for example, your own modules are collapsed out of the graph. It is not a compliance-grade SBOM, so don't feed it into supply-chain or audit tooling.

Why it is required

Master identifies every application by its groupId + artifactId. Those coordinates are how it groups instances, attributes state, and keys the persistence insights (N+1 and entity-mapping analysis).

Without the plugin the properties file is absent, the coordinates are blank, and Master rejects the registration — the instance never appears in the UI, no matter how the starter is configured. Applying the plugin is therefore a hard prerequisite for every managed service, not an optional enhancement.

Gradle and Maven

The plugin ships in two flavours, one per build tool:

Gradle — the com.axelixlabs.axelix plugin. It only needs the standard project group and version to be set; it fails the build if group is blank, since Axelix needs it to tell applications apart.
Maven — the axelix-maven-plugin, whose axelix-generate-project-info goal binds to the prepare-package phase. Maven always has its GAV coordinates, so nothing extra is required.

Neither flavour exposes any configuration options — you apply it and it does its job. The Gradle flavour additionally generates the dependency SBOM. See Configuring the build plugin for the exact snippets.

Configuring the build plugin — how to apply it with Gradle or Maven.
What is the Axelix Spring Boot Starter? — the runtime half that reads and reports the generated coordinates.