Built by Maven

Building DbUnit

Overview

Building DbUnit requires:

DbUnit ships with the Maven Wrapper at the repository root — mvnw for Unix/macOS/Git Bash, mvnw.cmd for Windows — so installing Maven manually isn’t necessary. The wrapper downloads and runs the exact Maven version pinned in .mvn/wrapper/maven-wrapper.properties the first time it’s invoked, so every contributor and CI runner builds with the same known Maven version, regardless of what the system may have installed.

Always invoke ./mvnw rather than a separately installed mvn.

Once having Java and Git, build DbUnit by just typing ./mvnw! The items below describe every step.

Generating the JAR

  1. Install the Java SE SDK and a Git client.
  2. Obtain DbUnit code, either current or released source (see Quick Links on left menu)
  3. On the root directory, simply type ./mvnw in the command line. The jar file generates in the target directory. (To clean up the binaries, run ./mvnw clean install instead.)

Quality Gates

Several plugins run as part of the normal build lifecycle and can change whether it succeeds:

Plugin When it runs Fails the build?
Modernizer verify phase Yes (failOnViolations=true) — flags use of an API with a more modern equivalent for the project’s target Java version. Skip locally with -DmodernizerPluginSkip=true (the same property the -Prelease and per-database profiles set internally).
Enforcer validate phase (the enforce goal’s default binding — the execution in pom.xml doesn’t override it) Yes — checks the Maven and Java versions in use, required plugin versions, and that referenced profile IDs actually exist.
Checkstyle site (reporting only) No. checkstyle.xml’s ruleset is wired only under the `reporting section — no execution binds a check goal to any lifecycle phase, so a violation shows up in the generated report (./mvnw site) but does not fail ./mvnw verify/./mvnw install/CI. Follow Java Style & Tooling's rules anyway; don’t rely on the build to catch all violations.
JaCoCo test/verify (report generation) No — produces a coverage report, does not gate the build on a coverage threshold.
japicmp site (reporting only) No — compares the current API against a prior release and reports differences; see Releasing for how its reportSets are updated each release cycle.

Surefire also has a skip property, -DsurefirePluginSkip=true, used internally by the release profiles (tests already ran earlier in the pipeline by the time those profiles build); it isn’t something typically used with local builds.

Both Surefire and Failsafe force -Duser.timezone=Europe/Berlin on every test run, so timestamp/timezone-sensitive behavior is exercised the same way in CI regardless of the runner’s own locale. A test launched directly from an IDE skips this unless its run configuration sets the same system property — see Test Conventions.

Generating the Site

The CI workflow generates and publishes the site gen from the main branch.

To locally build the site, run ./mvnw site in the command line; the site will be available on target/site/index.html. Note that an OutOfMemoryExceptionError may occur; if that happens, increase the heap size through the MAVEN_OPTS variable (for instance, on Unix systems, run MAVEN_OPTS=-mx512M ./mvnw site).

Deploying SNAPSHOT Builds

The CI workflow deploys SNAPSHOT builds from the main branch.

To manually deploy a SNAPSHOT build, also specify the source and javadoc goals so they are published along with the jar:

./mvnw clean source:jar javadoc:jar deploy

Verify Reproducible Build

  1. Run the normal build, installing to local repo for comparing to:
    ./mvnw clean install
  2. Run the reproducible build comparison step:
    ./mvnw clean verify artifact:compare
  3. Review the compare output for issues to fix.