main
Building DbUnit
Overview
Building DbUnit requires:
- Java SE SDK 8+
- Git client
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
- Install the Java SE SDK and a Git client.
- Obtain DbUnit code, either current or released source (see Quick Links on left menu)
- On the root directory, simply type
./mvnwin the command line. The jar file generates in the target directory. (To clean up the binaries, run./mvnw clean installinstead.)
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. |
Surefire (SiteAsciiDocTest) |
test phase |
Yes — fails when a page of README.adoc or
src/site/asciidoc puts an apostrophe or a letter directly after inline code (a possessive or
plural of a class name) or leaves a backtick without its partner, since Asciidoctor then shows a
stray backtick. The failure names the file and line and says how to reword the sentence. |
| Checkstyle | site (reporting only) |
No. The ruleset in checkstyle.xml 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).