Search Gradle plugins

org.flywaydb.flyway

Flyway is an open-source database migration tool. It strongly favors simplicity and convention over configuration. It is simple, focused and powerful. It runs on Windows, Mac OSX and Linux, Java and Android. It is based around just 6 basic commands: Migrate, Clean, Info, Validate, Baseline and Repair. Migrations can be written in SQL (database-specific syntax (such as PL/SQL, T-SQL, ...) is supported) or Java (for advanced data transformations or dealing with LOBs). It has a Command-line client. If you are on the JVM, we recommend using the Java API (also works on Android) for migrating the database on application startup. Alternatively, you can also use the Maven plugin, Gradle plugin, SBT plugin or the Ant tasks. And if that not enough, there are plugins available for Spring Boot, Dropwizard, Grails, Play, Griffon, Grunt, Ninja and more! Supported databases are Oracle, SQL Server, SQL Azure, DB2, DB2 z/OS, MySQL (including Amazon RDS), MariaDB, Google Cloud SQL, PostgreSQL (including Amazon RDS and Heroku), Redshift, Vertica, H2, Hsql Derby, SQLite and solidDB. More info: http://flywaydb.org

https://flywaydb.org/

Version 5.0.2 (latest)

Created 08 December 2017.

Flyway by Boxfuse is an open-source database migration tool. It strongly favors simplicity and convention over configuration. It is simple, focused and powerful. It runs on Windows, Mac OSX and Linux, Java and Android. It is based around just 6 basic commands: Migrate, Clean, Info, Validate, Baseline and Repair. Migrations can be written in SQL (database-specific syntax (such as PL/SQL, T-SQL, ...) is supported) or Java (for advanced data transformations or dealing with LOBs). It has a Command-line client. If you are on the JVM, we recommend using the Java API (also works on Android) for migrating the database on application startup. Alternatively, you can also use the Maven plugin, Gradle plugin, SBT plugin or the Ant tasks. And if that not enough, there are plugins available for Spring Boot, Dropwizard, Grails, Play, Griffon, Grunt, Ninja and more! Supported databases are Oracle, SQL Server, SQL Azure, DB2, DB2 z/OS, MySQL (including Amazon RDS), MariaDB, Google Cloud SQL, PostgreSQL (including Amazon RDS and Heroku), Redshift, Vertica, H2, Hsql Derby, SQLite and solidDB. More info: https://flywaydb.org

Build script snippet for use in all Gradle versions:

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "gradle.plugin.com.boxfuse.client:flyway-release:5.0.2"
  }
}

apply plugin: "org.flywaydb.flyway"

Build script snippet for new, incubating, plugin mechanism introduced in Gradle 2.1:

plugins {
  id "org.flywaydb.flyway" version "5.0.2"
}

Why?

The new way to add plugins to a project is much more than a more convenient syntax. The new DSL is processed very differently to the old one. The new mechanism allows Gradle to determine the plugins in use very early and very quickly. This allows Gradle to do smart things such as:

  • Optimize the loading and reuse of plugin classes.
  • Allow different plugins to use different versions of dependencies.
  • Provide editors detailed information about the potential properties and values in the buildscript for editing assistance.

This requires that plugins be specified in a way that Gradle can easily and quickly extract, before executing the rest of the build script. It also requires that the definition of plugins to use be somewhat static.

There are some key differences between the new plugin mechanism and the “traditional” apply() method mechanism. There are also some constraints, some of which are temporary limitations while the mechanism is still being developed and some are inherent to the new approach.

Constrained syntax.

The new plugins {} block does not support arbitrary Groovy code. It is constrained, in order to be idempotent (produce the same result every time) and side effect free (safe for Gradle to execute at any time).

The form is:

plugins {
    id «plugin id» version «plugin version»
}

Where «plugin version» and «plugin id» must be constant, literal, strings. No other statements are allowed; their presence will cause a compilation error.

The plugins {} block must also be a top level statement in the buildscript. It cannot be nested inside another construct (e.g. an if-statement or for-loop).

Can only be used in build scripts.

The plugins {} block can currently only be used in a project's build script. It cannot be used in script plugins, the settings.gradle file or init scripts.

Future versions of Gradle will remove this restriction.

Cannot be used in conjunction with subprojects {}, allprojects {} etc.

It is not possible to use the familiar pattern of applying a plugin to multiple projects at once using subprojects {} etc. at the moment. There is currently no mechanism for applying a plugin to multiple projects at once. At the moment, each project that requires a plugin must declare so in the plugins {} block in its buildscript.

Future versions of Gradle will remove this restriction.

If the current limitations of the new plugin mechanism are problematic for your build, the recommended approach is to use the “traditional” mechanism for the time being.