Maven Plugin

dev.kensa:kensa-maven-plugin provides one mojo: assemble-site. It does the same job as Gradle's assembleKensaSite task — collects every sources/<id>/ bundle that test executions wrote into a shared site root and produces the shell + manifest on top.

The Maven plugin does not wire system properties for you; you set them on each surefire/failsafe execution. This keeps the surface minimal and avoids interfering with existing surefire configurations.

Apply

pom.xml

<plugin>
  <groupId>dev.kensa</groupId>
  <artifactId>kensa-maven-plugin</artifactId>
  <version>${kensa.plugin.version}</version>
  <executions>
    <execution>
      <id>assemble-site</id>
      <phase>post-integration-test</phase>
      <goals><goal>assemble-site</goal></goals>
      <configuration>
        <expectedSourceIds>
          <expectedSourceId>uiTest</expectedSourceId>
          <expectedSourceId>scenarioTest</expectedSourceId>
        </expectedSourceIds>
      </configuration>
    </execution>
  </executions>
</plugin>

You also need dev.kensa:kensa-core on the test classpath — the Kotlin compiler plugin and runtime are responsible for emitting per-source bundles, the Maven plugin only assembles them.

Mojo configuration

Parameter	Default	Effect
siteRoot	${project.build.directory}/kensa-site	Site root directory.
expectedSourceIds	(required)	List of source ids the manifest should include. Same set you pass via kensa.source.id to the per-execution test runs.
kensaVersion	${plugin.version}	Recorded in manifest.json.

Driving per-source bundles via surefire/failsafe

Each test execution that should produce its own source bundle sets kensa.output.root and kensa.source.id (and optionally kensa.source.title) via systemPropertyVariables:

pom.xml — failsafe per-execution wiring

<plugin>
  <artifactId>maven-failsafe-plugin</artifactId>
  <executions>
    <execution>
      <id>uiTest</id>
      <goals><goal>integration-test</goal></goals>
      <configuration>
        <systemPropertyVariables>
          <kensa.output.root>${project.build.directory}/kensa-site</kensa.output.root>
          <kensa.source.id>uiTest</kensa.source.id>
          <kensa.source.title>UI Tests</kensa.source.title>
        </systemPropertyVariables>
      </configuration>
    </execution>
    <execution>
      <id>scenarioTest</id>
      <goals><goal>integration-test</goal></goals>
      <configuration>
        <systemPropertyVariables>
          <kensa.output.root>${project.build.directory}/kensa-site</kensa.output.root>
          <kensa.source.id>scenarioTest</kensa.source.id>
        </systemPropertyVariables>
      </configuration>
    </execution>
  </executions>
</plugin>

When kensa.source.id is set, Kensa core writes its bundle to ${kensa.output.root}/sources/${kensa.source.id}/ instead of the default ${kensa.output.root}/kensa-output/. This is the same runtime contract that powers the Gradle plugin — see Site Mode for the disk layout.

Multi-module builds

Bind the assemble-site execution on the root pom.xml and set siteRoot to a shared location (e.g. ${session.executionRootDirectory}/target/kensa-site). Every submodule's surefire/failsafe execution writes into that shared root using its own kensa.source.id; the root-level assemble-site then aggregates.

Run

mvn verify

The assemble-site goal binds to post-integration-test, so it runs after all *-IT tests have written their per-source bundles. Open target/kensa-site/index.html afterwards.

Source IDs and titles

Same contract as Gradle:

Property	Effect
kensa.source.id	Per-source bundle directory name. Required to opt into site mode (otherwise Kensa core writes to the default kensa-output/ location).
kensa.source.title	Overrides Configuration.titleText — the label shown for that source in the sidebar.

If kensa.source.title is not set, the source's sidebar label falls back to whatever Configuration.titleText was set to programmatically (or "Index" if untouched).

Limitations relative to the Gradle plugin

• No automatic source-id collision detection — set unique ids per execution yourself.
• No partial-run warnings — the mojo logs a notice for missing expected sources but doesn't fail the build (same behaviour as Gradle).
• The mojo is @DisableCachingByDefault equivalent — Maven has no build cache to participate in. Re-running rebuilds the manifest unconditionally.