The Maven Parent

The Gradle plugin's counterpart is a parent POM, spider-silk-maven-parent, whose pluginManagement and profiles carry the same packaging. Maven shares build conventions by inheritance rather than by plugin: a Maven plugin runs goals, and cannot declare other plugins' configuration the way a Gradle plugin can.

<parent>
  <groupId>net.benelog.spidersilk</groupId>
  <artifactId>spider-silk-maven-parent</artifactId>
  <version>1.1.0</version>
</parent>

The parent is published to Maven Central, which Maven searches by default, so the <parent> block needs no repository or settings.xml entry beside it.

Opting in by declaring

Everything sits in the parent’s pluginManagement, so it stays inert until the child declares the plugin. The declaration is the opt-in, the way spiderSilk { jte() } is on the Gradle side. A child that containerizes and precompiles jte declares both, and configures only what is the application’s own:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jar-plugin</artifactId>
      <configuration>
        <archive>
          <manifest>
            <mainClass>flashcard.FlashcardApp</mainClass>
          </manifest>
        </archive>
      </configuration>
    </plugin>
    <plugin>
      <groupId>com.google.cloud.tools</groupId>
      <artifactId>jib-maven-plugin</artifactId>
      <configuration>
        <to>
          <image>ghcr.io/benelog/spider-silk-flashcard:${spider-silk.image.tag}</image>
        </to>
      </configuration>
    </plugin>
    <plugin>
      <groupId>gg.jte</groupId>
      <artifactId>jte-maven-plugin</artifactId>
    </plugin>
    <plugin>
      <groupId>org.graalvm.buildtools</groupId>
      <artifactId>native-maven-plugin</artifactId>
    </plugin>
  </plugins>
</build>

The main class is declared once, in the jar manifest where a runnable jar wants it anyway. Jib infers its entrypoint from there, and native-maven-plugin reads the same entry for the binary. Configuring it on either plugin instead would work, until the two drift.

What the declarations inherit mirrors the Gradle plugin’s conventions:

  • Jib builds on eclipse-temurin:21-jre and exposes port 8080. mvn package jib:buildTar writes target/jib-image.tar with no Docker daemon involved, layered as Deployment describes.

  • maven.compiler.release is set to 21, which doubles as where Jib reads the Java version it checks against the base image. The targetCompatibility wrinkle the Gradle plugin absorbs has no Maven counterpart to absorb.

  • jte precompiles every template under src/main/resources/jte at build time, native-image resources included, exactly as Templates describes.

  • The native binary builds with <fallback>false</fallback>, mostly static (--static-nolibc, so the distroless/base container owes it nothing but glibc), and the reachability metadata repository enabled. It is named ${spider-silk.native.image-name}, which is the artifactId unless the property says otherwise.

The native profile

mvn -Pnative package jib:buildTar ships the GraalVM binary instead of the jar. The profile binds native:compile-no-fork to package, swaps Jib’s base for distroless/base, and attaches Jib’s native-image extension pointed at the same binary name. The native image chapter walks through that switch.

The ${spider-silk.image.tag} placeholder in the child’s image name above is what keeps the two images apart: the parent defaults it to latest, the profile flips it to native, and a child that hard-codes a tag instead opts out of the distinction.

Dockerfile warm-up

mvn dependency:go-offline is the Maven counterpart to the Gradle plugin’s resolveDependencies, where a platform demands a Dockerfile. It downloads the dependencies and plugins for the warm-up layer, and runs after copying the pom alone, the way the Gradle Dockerfile copies the build scripts.

What the parent pins

The parent’s version fixes the versions of what it manages: jte 3.2.4, Jib 3.5.2 (the Maven plugin lags the Gradle plugin’s 3.5.4 upstream), and the GraalVM build tools 1.1.10. A toolchain bump arrives as a parent release. As on the Gradle side, nothing here is beyond plain Maven: every convention is readable in the parent POM itself, and a build that would rather own a block copies it out and drops the inheritance.