search

tlberglund / groovy-liquibase

Yet Another Groovy DSL for Liquibase
Other
85 stars 66 forks source link

Updating groovy-liquibase DSL #45

Closed kenshaw closed 9 years ago

kenshaw commented 9 years ago

I've taken the liberty of bumping the underlying liquibase support (to 3.3.2), and fixed some aspects of the unit tests / calls to work with the underlying API changes. I've also done some file cleanup to standarize things a bit. I've also bumped the version from 1.0.x to 3.3.x to better follow the liquibase releases (in case there's another breaking API change in the future).

This was needed, as features in liquibase 3.3.x were needed for a project that we're currently working on.

stevesaliman commented 9 years ago

When I tried to update to Liquibase 3.2, I immediately ran into problems due to changes with the way dates were handled (https://liquibase.jira.com/browse/CORE-1931), which prevented me from updating at that time. Ultimately, using the new ParsedNode objects as an abstraction layer between DSLs and Liquibase is the way to go, but I don't want to use them until https://liquibase.jira.com/browse/CORE-1968 gets fixed.

I wasn't aware that anything had changed, but perhaps Liquibase 3.3 has made some changes that makes things work. I'll take a look at this over the weekend.

stevesaliman commented 9 years ago

I took a look at the changes in Liquibase 3.3, and it doesn't fix the referenced Jira issues, but the idea of having my own copy of ObjectUtil in the groovy parser (at least until ParsedNodes work properly) is a really good one. I was able to patch the Liquibase 3.3 ObjectUtil class to do what I needed.

While this pull request does run in Luquibase 3.3, it doesn't support luquibase 3.3. The goal of the Groovy DSL is to support everything that the XML parser supports, and so far, the code doesn't support things like the labels attribute or the new renameSequence change.

Your idea of the local copy of ObjectUtil did get me going however, and I've just pushed new code to GitHub that appears to fully support Liquibase 3.3.2. I still need to do some research and testing, and I need to update the Liquibase plugin. I hope to have that done in the next week or so, at which time I'll do an official release.

kenshaw commented 9 years ago

Cool -- I'm not offended if you don't want to use my code, or implement a better version ... just if you could make sure to add support for the diffChangeLog.

I am aware of what I wrote lacking the labels support, however I had needed other functionality that wasn't in the 3.1.x branch, and thus wanted to get out a fix to support the fixes that we needed.

BTW -- if you try to use the diffChangeLog support, please note that Liquibase's 3.3.x branch is broken, and you should probably merge Liquibase's commit f1d82ee9 to the 3.3.x branch if you want to try out the diffChangeLog feature. I don't know why they haven't done a point release to merge this into 3.3.x, but I think it speaks volumes about the Liquibase project in itself, especially considering that it has been broken for months, and that I have sent emails to the developers about this issue that continue to go unanswered.

stevesaliman commented 9 years ago

I've just uploaded the 1.0.1-SNAPSHOT releases of both the DSL and the plugin to Sonatype's staging repository.

They now fully support Liquibase 3.3.2 (including diffChangeLog), but I have no idea how to create a dependency to a specific commit. As far as I know, I can only declare a build.gradle dependency to a specific, released, artifact version.

As a workaround, you could clone the Liquibase project, checkout the specific commit of interest, build the project locally, and override the org.liquibase:liquibase-core dependency of the plugin in your project's build.gradle file.

Give it a try, and let me know how it works out. I should have a relase ready by the weekend.

stevesaliman commented 9 years ago

Version 1.0.1 of the Groovy DSL and Gradle plugin have been released, which include support for Liquibase 3.3.2