Java.DBMigrationTools.How does Flyway integrate with Gradle or Maven?

Flyway integrates with Maven and Gradle via official plugins that expose Flyway commands as build goals/tasks (migrate, validate, info, baseline, repair, clean), and by letting you configure Flyway the same way you would in app runtime: URL/user/password, locations, schemas, placeholders, config files, etc.

---

Maven integration (Flyway Maven Plugin)

How you use it

• Add the Flyway plugin to pom.xml
• Run goals like:
  • mvn flyway:migrate
  • mvn flyway:validate
  • mvn flyway:info
  • mvn flyway:baseline
  • mvn flyway:repair

The plugin is designed so configuration can come from multiple places with a clear precedence order (system properties/env vars/config files/Maven properties/plugin config/settings.xml creds/~/.flyway.conf).

Typical Maven setup (conceptually)

• Put SQL migrations under the usual default: src/main/resources/db/migration (or configure locations)
• Configure DB connection in plugin config or via properties (often from CI secrets)
• Call flyway:migrate in CI, or during a dedicated pipeline stage (not necessarily on every local build)

---

Gradle integration (Flyway Gradle Plugin)

How you use it

• Apply plugin org.flywaydb.flyway (from Gradle Plugin Portal)
• Run tasks like:
  • gradle flywayMigrate
  • gradle flywayValidate
  • gradle flywayInfo
  • gradle flywayBaseline
  • gradle flywayRepair
  • gradle flywayClean (dangerous outside local/dev)

Config and config files

• You can configure via flyway { ... } in build.gradle(.kts) or use config files.
• The Gradle plugin supports ~/.flyway.conf and can load additional config files via -Dflyway.configFiles=....

---

Common patterns in real projects

1) “CI runs migrations” (most common for services)

• CI stage: validate → migrate
• App startup doesn’t need to run migrations (or you keep it enabled, but you must be intentional about it).

2) “App runs migrations on startup” (common with Spring Boot)

• Add flyway-core dependency and Flyway runs automatically at startup when configured.
• Still keep the plugin for local/CI tooling if useful.

3) Separate DB user for migrations

• Use elevated “migration user” for Flyway runs, limited “app user” at runtime.