Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradle Plugin #78

Closed
flyway opened this issue Jun 25, 2013 · 30 comments
Closed

Gradle Plugin #78

flyway opened this issue Jun 25, 2013 · 30 comments

Comments

@flyway
Copy link
Collaborator

@flyway flyway commented Jun 25, 2013

Original author: axel.fontaine.business@gmail.com (February 03, 2011 21:50:00)

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

Original issue: http://code.google.com/p/flyway/issues/detail?id=88

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From gerwin.b...@gmail.com on October 11, 2012 10:08:54
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

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From axel.fontaine.business@gmail.com on October 11, 2012 12:09:01
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

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From Ben.Ma...@gmail.com on October 11, 2012 16:57:04
fyi, some support is provided with the mysql plugin. It may be a good example.

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

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From gerwin.b...@gmail.com on October 11, 2012 17:05:22
Hi,

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

Best,
Gerwin

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From vatsa.ka...@gmail.com on October 24, 2012 11:40:01
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..

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From vatsa.ka...@gmail.com on October 24, 2012 14:08:33
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"

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From axel.fontaine.business@gmail.com on October 25, 2012 08:51:49
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

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From vatsa.ka...@gmail.com on October 25, 2012 15:27:19
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.

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From vatsa.ka...@gmail.com on October 26, 2012 06:42:19
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

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From vatsa.ka...@gmail.com on October 26, 2012 06:43:16
Updated the documentation on the project wiki (https://github.com/katta/gradle-flyway-plugin)

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From axel.fontaine.business@gmail.com on October 31, 2012 12:52:49
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

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From vatsa.ka...@gmail.com on October 31, 2012 16:32:19
Sure will get these things fixed.

Thanks,
Katta

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From axel.fontaine.business@gmail.com on December 15, 2012 10:27:51
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

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From vatsa.ka...@gmail.com on December 19, 2012 13:12:52
Sure Axel, am stuck with getting Groovy API plugin working with Maven. Will give it a shot for some more time and update on where I stand on this in a weeks time.

-katta

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From vatsa.ka...@gmail.com on January 21, 2013 04:09:05
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

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From axel.fontaine.business@gmail.com on January 21, 2013 10:01:00
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

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From axel.fontaine.business@gmail.com on January 21, 2013 10:05:48
Another alternative would be to set up a separate GitHub repository with GitHub pages to act as a Maven repository for artifacts like this...

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From msz...@wp.pl on January 21, 2013 11:32:58
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

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From Ben.Ma...@gmail.com on March 03, 2013 14:23:55
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.

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From axel.fontaine.business@gmail.com on March 03, 2013 22:23:47
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

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From Ben.Ma...@gmail.com on March 03, 2013 23:36:00
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.

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From Ben.Ma...@gmail.com on March 04, 2013 03:08:09
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).

  1. 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.

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From Ben.Ma...@gmail.com on March 10, 2013 01:30:41
Added integration into maven's build lifecycle

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From axel.fontaine.business@gmail.com on March 12, 2013 09:51:05
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

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From Ben.Ma...@gmail.com on March 13, 2013 10:10:32
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.

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From jasonlow...@gmail.com on April 05, 2013 13:14:23
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!

Loading

@flyway
Copy link
Collaborator Author

@flyway flyway commented Jun 25, 2013

From Ben.Ma...@gmail.com on April 05, 2013 22:26:38
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

Loading

@szpak
Copy link

@szpak szpak commented Jun 25, 2013

+1

Loading

1 similar comment
@dasAnderl
Copy link

@dasAnderl dasAnderl commented Jun 27, 2013

+1

Loading

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Jul 12, 2013

Implemented.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants