Configuring the Axelix Build Plugin
Applying the Axelix build plugin stamps your build coordinates into the artifact so Axelix Master can identify the instance.
Applying the Axelix build plugin is the second half of making a service visible to Axelix Master — the first half is wiring up the starter. The plugin has nothing to configure: you apply it, and it stamps your build coordinates into the artifact so Master can identify the instance. See What is the Axelix build plugin? for what it produces and why it is required.
Required for registration
Master identifies every application by its groupId + artifactId. Without the plugin the
META-INF/axelix-info.properties file is absent, the coordinates are blank, and Master rejects the registration —
the instance never appears in the UI. The same coordinates also key the persistence
insights (N+1 and entity-mapping analysis). Apply the plugin to every
service you want Axelix to manage.
The plugins are currently published to Maven Central only. Publishing to the Gradle Plugin Portal is on the roadmap;
until then, Gradle builds must resolve the plugin from Maven Central (see the pluginManagement block below). Keep the
plugin version in sync with the starter version.
Apply the plugin
Because the plugin is not on the Gradle Plugin Portal yet, add mavenCentral() to pluginManagement in your
settings.gradle.kts:
pluginManagement {
repositories {
gradlePluginPortal()
mavenCentral()
}
}Then apply the plugin in build.gradle.kts:
plugins {
id("com.axelixlabs.axelix") version "1.1.1"
}Neither plugin exposes any configuration options. The Gradle plugin 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
always has its GAV coordinates, so nothing else is required.
Optional group coordinate
In the early days, Axelix required all the Java apps that it manages to have the groupId (the G part of the GAV). But
since 1.2.0 release it is no longer the case.
Technically speaking, every Java application that is packaged and deployed is supposed to be a Maven Artifact. However, there are cases when the application is not really supposed to be deployed to the Maven-compatible binary repository. It might be, for example, if the application is just assembled as the docker image on the flight and deployed to K8S cluster.
In this case, the Java application is not required to be a complete Maven artifact (since it is not technically deployed
to Nexus/Artifactory), and in particular, it is not really required to have groupId. Specifically because of this,
Gradle allows the Java applications that are not supposed to be deployed as Maven Artifacts to omit the groupId.
Thus, Axelix is now capable to handle projects with no groupId. In this case, Axelix simply assumes that
such applications have the empty groupId (i.e. ""). As a result, if you omit the usage of groupId in your organization for your
Java microservices, then you must ensure that the names your microservices (i.e. the name attribute in your build.gradle.kts files,
which resolves to artifactId) are unique. If the names will not be unique, then Axelix Master's behavior with your spring boot
applications is undefined.
Related
- What is the Axelix build plugin? — what the plugin generates and why registration depends on it.
- Configuring the Spring Boot Starter — the runtime side that reads the generated coordinates and reports them to Master.