Issue 88 in flyway: Gradle Plugin

[fly...@googlecode.com]

Status: New
Owner: axel.fontaine.business
CC: bartl.da...@googlemail.com
Labels: Type-Enhancement Priority-Medium

New issue 88 by axel.fontaine.business: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Small wrapper around the Flyway class, similar to the Maven Plugin

[fly...@googlecode.com]

Comment #1 on issue 88 by gerwin.b...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hi Axel,

I'm currently looking into figuring out how we could create a plugin for
Gradle (I know you have it on the road map, but it is quite far away)

Have you already thought about how to implement this? Could you share your
thoughts on that with me.
If you would be interested you could reuse/integrate the code we create
into your version.

Best,
Gerwin

[fly...@googlecode.com]

Updates:
Status: Accepted

Comment #2 on issue 88 by axel.fontai...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hi Gerwin,

as with the Maven, Ant and Command-Line wrappers, the Gradle plugin should
be just a very thin wrapper around the Flyway class.

The api should match that of the others very closely. In fact method and
property names should be identical. The only difference might be
Gradle-specific things. These however can always be added later. At first,
simply strive to get all base methods and properties working (with
appropriate documentation).

The roadmap is not set in stone. If you have implemented and documented the
plugin, we certainly can look at integrating it in the official
distribution sooner.

When in doubt about something, do not hesitate to ask. I will do my best to
assist you.

Cheers
Axel

[fly...@googlecode.com]

Comment #3 on issue 88 by Ben.Ma...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

fyi, some support is provided with the mysql plugin. It may be a good
example.

https://github.com/andreassimon/gradle-mysql-plugin

[fly...@googlecode.com]

Comment #4 on issue 88 by gerwin.b...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hi,

thanks for the resources.
I'll take a look at them and see what I can come up with :)

Best,
Gerwin

[fly...@googlecode.com]

Comment #5 on issue 88 by vatsa.ka...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

I have created one which you can find here
https://github.com/katta/gradle-flyway-plugin

Am yet to make a release version of this and publish to some maven public
repository so that others can use it easily with out having to build from
source code.

Any feedback is welcome..

[fly...@googlecode.com]

Comment #6 on issue 88 by vatsa.ka...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Have uploaded the version 1.0 @ http://katta.github.com/repository

[fly...@googlecode.com]

Comment #7 on issue 88 by vatsa.ka...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Have uploaded the release version 1.0 @ http://katta.github.com/repository

Use this URI as maven repository and use flyway dependency
as "org.gradle.api.plugins:flyway:1.0"

[fly...@googlecode.com]

Comment #8 on issue 88 by axel.fontai...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hi Srivatsa,

Thanks for contributing this! I had a brief look at it (will have more time
next week).

Some things I noticed:
- groupId: why org.gradle.api.plugins? Isn't this reserved for the bundled
Gradle plugins?
- configFile: while this exists out of necessitity for the command-line
tool, I would much prefer the Gradle plugin to be configurable directly
with individual properties
- status/history/info: Why did you reimplement the ascii renderer? Is it
not sufficient for Gradle's purposes?

Keep up the great work,
Axel

[fly...@googlecode.com]

Comment #9 on issue 88 by vatsa.ka...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Thanks for the feedback Axel.

groupId - Will change the groupId

configFile - As there are too many properties for flyway tasks I thought
its easier to get started with the properties file to start with. Totally
agree that configuring these with plugin way makes it consistent with other
plugins, will work on it.

How about still keeping the configFile but anything that is configured in
the plugin will override the ones in properties file ? or is it over kill ?

- status/history/info - The flyway API returns POJOs for these calls which
does not have toString implemented, and am not still expert @ groovy API so
the old style StringBuilder :P Let me know if there is a better way to
handle these will incorporate it.

[fly...@googlecode.com]

Comment #10 on issue 88 by vatsa.ka...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hi Axel,

I have made changes for groupId and how config is provided.

Got rid of support for configFile and the lastest version expects the
config to be specified in a flyway closure (using plugin extensions for
this)

Do let me know if you have any further feedback.

-Katta

[fly...@googlecode.com]

Comment #11 on issue 88 by vatsa.ka...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Updated the documentation on the project wiki
(https://github.com/katta/gradle-flyway-plugin)

[fly...@googlecode.com]

Comment #12 on issue 88 by axel.fontai...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hi Katta,

Some further feedback:

- Can you make FlywayPluginExtension more strongly typed? Everything there
is a string even though some things could be booleans, collections,
enums, ...
- What about documentation? Are there any opportunities for adding docs so
that IDE users (IntelliJ, Eclipse) can see them when invoking completion?
(The fields of FlywayPluginExtension?) Might need testing to see what the
respective Gradle IDE plugins allow.
- Could you transition the build to Maven? This will then allow the plugin
to be integrated in the main Flyway distribution and build once it is ready.

Keep it up!
Axel

[fly...@googlecode.com]

Comment #13 on issue 88 by vatsa.ka...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Sure will get these things fixed.

Thanks,
Katta

[fly...@googlecode.com]

Comment #14 on issue 88 by axel.fontai...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hi Katta,

Flyway has now moved to GitHub: https://github.com/flyway/flyway

Could you update the Gradle Plugin to match the latest 2.0.3 functionality?
For the Gradle plugin we can start fresh and not implement all the
deprecated stuff still around in the others.

Let me know if you need assistance and give me a shout when you're ready to
submit a pull request for inclusion in the mainline. (Don't forget
documentation!)

Thanks :-)
Axel

[fly...@googlecode.com]

Comment #16 on issue 88 by vatsa.ka...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hi Axel,

I might need your help here.

I moved the build script to maven from groovy but the problem is am not
able to find gradle libraries in any of the public maven repositories. I am
forced to setup my own repository @ katta.github.com/repository and
uploading each of the gradle libraries. And there are too many of them. I
can get the project compiling but not able to run tests as lot of runtime
dependencies happens to be most of gradle-core dependencies.

Somehow not convinced with this approach, any other ideas to get around
this problem ?

-katta

[fly...@googlecode.com]

Comment #17 on issue 88 by axel.fontai...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hi Katta,

there is a Gradle Issue for this: http://issues.gradle.org/browse/GRADLE-392

Let's start by voting it up!

Until it is fixed, we will have to come up with an alternative solution
(force automatic download into local Maven Repository using maven plugins
or ant tasks, or add a section to the dev environment setup page to do it
manually)

Cheers
Axel

[fly...@googlecode.com]

Comment #18 on issue 88 by axel.fontai...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Another alternative would be to set up a separate GitHub repository with
GitHub pages to act as a Maven repository for artifacts like this...

[fly...@googlecode.com]

Comment #19 on issue 88 by msz...@wp.pl: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Btw, GitHub recently disabled an ability to upload binary files to a
download section, which can complicate using it as an artifacts repository:
https://github.com/blog/1302-goodbye-uploads

[fly...@googlecode.com]

Comment #20 on issue 88 by Ben.Ma...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

I ran into some corner cases that either Katta's plugin didn't handle. I
wrote a new one based on Flyway v2.0.3 in order to investigate and resolve
these problems.

In particular it took me a few attempts to correctly indicate to Gradle
that the migration task is up-to-date. This was because the up-to-date
closure cannot load the database driver due to the classpath not being
setup yet. I needed this functionality for my jOOQ codegen plugin.

https://github.com/ben-manes/gradle-flyway-plugin

I'd like this plugin to be able to create a schema is not present
(schema-per-service). This appears to be on the roadmap for 2.1. Do you
know when that will be ready for release? If not soon, than I can add this
to my plugin. I am trying to setup a build process where flyway migrates
H2, codegens jOOQ, compiles, and tests. This would allow me to avoid
checking in codegen code and have it be a build artifact.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[fly...@googlecode.com]

Comment #21 on issue 88 by axel.fontai...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hi Ben,

thanks for contributing this!

The schema creation code is already in SCM.

Ideally I would like the Gradle integration to be part of the official 2.2
release.

For this the plugin would need:
- to also load and execute Java-based migrations
- to be integrated in the Maven build, so that issuing mvn clean install in
the root will also build the Gradle plugin. (do not worry about artifacts
not being present on Maven Central. A temporary Maven repository can be set
up on flywaydb.org until they are)

Cheers
Axel

[fly...@googlecode.com]

Comment #22 on issue 88 by Ben.Ma...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

The plugin turned out to be very similar to Katta's, so he deserves most of
the credit. Since he has the Maven parts done that might be the basis.

I think Java-based migrations might be a bit tricky. That requires that the
code be compiled and on the classpath, which inverts my flow with jOOQ. For
me it would require that my Java migrations are in a separate project, I
think, which is a bit ugly. It gets messy if the code has library
dependencies, etc. This may require changing the plugin to use the Flyway
command-line instead of the Java api. I might peek at how the Maven plugin
handles this...

If I understand the liquidbase plugin correctly, it tries to solve this by
using Groovy scripts and not supporting library dependencies. That lets it
be decoupled from the compile step and perhaps something similar could be
achieved with flyway. (See
https://github.com/tlberglund/gradle-liquibase-plugin)

There may be an elegant solution, but on a first glance it appears messy.

[fly...@googlecode.com]

Comment #23 on issue 88 by Ben.Ma...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Giving this more thought, I don't think my concerns are valid. There are
two scenarios,

1) Migrate then compile
This is the approach I'm adopting for my needs. This assumes that Gradle is
not uses as the release tool, which imho is preferable. I would want more
control over the release than what a build tool provides.

The Gradle plugin is used only for the subsequent code generation phase.
This requires SQL migration scripts for schema changes. For a release the
compiled unit would be run so that the Java migration scripts are included,
which would be data migrations / fixes or vendor-specific schema updates
(e.g. partitioned tables).

2) Compile then migrate
This should work fine in Gradle and appears to be the expectation for the
Maven plugin. There might be a minor change or two required if this doesn't
work presently. I'll put together another example project demonstrating
that configuration.

[fly...@googlecode.com]

Comment #24 on issue 88 by Ben.Ma...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Added integration into maven's build lifecycle

[fly...@googlecode.com]

Comment #25 on issue 88 by axel.fontai...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hi Ben, hi Katta,

thanks guys! The next step I see would be to prepare and start working on a
joint pull request against the main flyway repository. We could then
gradually refine it and clean it up until it is ready for being pulled in
so it can become part of Flyway 2.2.

Additionally, to make this well rounded there should be another pull
request against docs on the main website to contribute a first steps guide
for Gradle as well as specific documentation pages (similar to Maven, Ant
and Command-line docs)

Keep up the great work!
Axel

[fly...@googlecode.com]

Comment #26 on issue 88 by Ben.Ma...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Added pull request for iteration. I did not investigate to match the
project's style (e.g. spaces).

I added basic integration into the Maven build. Due to the concerns
expressed earlier for Maven integration, I took a different approach by
having Maven invoke the Gradle build. I think we will need to verify that
the deploy/release plugins correctly capture the artifacts, or the project
poms will need some additional modifications.

This is identical to my before mentioned plugin with the package names
changed and tighter integration into your build.

[fly...@googlecode.com]

Comment #27 on issue 88 by jasonlow...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hey guys,

I'm new to the Flyway experience, and I'm currently researching database
automation for my organization. We've become heavy gradle users, so this
plug-in would certainly help us out.

If you guys would let me know when you're officially ready to include the
gradle plug-in, I'd appreciate it. Also, any advice you'd have during my
research, I'd certainly welcome. I'll keep my eye on this thread, for
sure. Keep it up!

[fly...@googlecode.com]

Comment #28 on issue 88 by Ben.Ma...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Hi Jason,

Java migrations are now supported in the plugin [1] and will be released by
the end of the weekend. The remaining open tasks involve integration into
Flyway's maven build and release process, as well as following up with
Axel's code review comments. I've prototyped this but I don't have an
estimate of when I'll have that completed.

You should be able to use the plugin now while it is not part of Flyway
proper.

[1] https://github.com/ben-manes/gradle-flyway-plugin

[fly...@googlecode.com]

Updates:
Status: Migrated
Cc: -bartl.da...@googlemail.com

Comment #29 on issue 88 by axel.fontai...@gmail.com: Gradle Plugin
http://code.google.com/p/flyway/issues/detail?id=88

Migrated to GitHub: https://github.com/flyway/flyway/issues/78

To everyone who starred this issue: please leave a +1 comment on the linked
GitHub issue