Reference

Maven plugin

The build plugin runs the same pipeline the CLI runs, during your application's build, and writes the tool manifest onto the classpath. Nothing is committed by hand, and rebuilding regenerates it from whatever your source now says.

Bound execution (recommended)

Add the plugin to your application's pom.xml. Its generate goal binds to the generate-resources phase by default, so a normal mvn package produces the manifest.

pom.xml

<plugin>
  <groupId>io.github.tibyaan-org</groupId>
  <artifactId>tibyan-maven-plugin</artifactId>
  <version>0.3.0</version>
  <executions>
    <execution>
      <goals><goal>generate</goal></goals>
    </execution>
  </executions>
</plugin>

shell

mvn package

One-off invocation

Run the goal directly with its fully qualified coordinates, with no pom change:

shell

mvn io.github.tibyaan-org:tibyan-maven-plugin:0.3.0:generate

The short form mvn tibyan:generate also works if the plugin group is on your Maven plugin search path.

What the goal does

Behavior	Detail
Default phase	`generate-resources`
Output	`tibyan/capabilities.json` in the classpath output directory (`target/classes`).
Resilience	Resilient by default: an unparseable file is skipped and named at WARN, and the manifest is generated from what was discovered. A partial manifest is disclosed loudly.
Zero capabilities	If nothing is discovered, the build succeeds but logs a WARN telling you to run `tibyan scan` to see why.
Hard failures	A genuinely invalid model, or an unwalkable source root, still fails the build.

Parameters

Each parameter has a -D property for command-line override.

Parameter	Property	Default	Purpose
`sourceRoot`	`tibyan.sourceRoot`	`${project.basedir}`	The source root to scan.
`outputDirectory`	`tibyan.outputDirectory`	`${project.build.outputDirectory}`	Where the manifest is written.
`workDirectory`	`tibyan.workDirectory`	`${project.build.directory}/tibyan-generate`	Intermediate directory for the backend's full output.
`strict`	`tibyan.strict`	`false`	When true, any unparseable file or hard failure fails the build.

Resilient and strict

The default is built so that adopting the plugin never breaks a build on a bad file. For a CI gate, turn strictness on:

shell

mvn package                        # resilient default
mvn package -Dtibyan.strict=true   # fail the build on any unparseable file (CI gate)

Keep versions together

Keep the runtime dependency and the plugin at the same version. Before 1.0.0, treat every minor bump as potentially breaking: the manifest format is additive where possible but not yet stable. The changelog (opens in a new tab) lists what an adopter should read before upgrading.

Multi-module builds

In a reactor, sourceRoot defaults to the single module the plugin runs in, which is usually not what you want. Point it at the reactor root so one manifest covers every module, on the classpath of the module that runs. The recipe is in Multi-module applications.

The authoritative text is docs/COMMANDS.md, section 3 (opens in a new tab) in the repository. If this page and that document ever disagree, the repository wins.