不幸的是，db migration plugin仍然存在liquibase的2.0.5版本，它有很多错误，其中一些是我们的阻止。但是，liquibase 3.3。解决了所有问题。
我们没有编辑或修改Burt编写的迁移插件所需的专业知识。
我们需要使用插件，因为我们需要能够在部署战争时自动运行liquibase更新，我们无法访问的atremote客户站点（我们只提供战争，部署它）。
一种解决方案可能是“破解”3.3。 liquibase jar in。我们看到比home.grails \ ivy-cache \ org.liquibase \ liquibase-core是liquibase-core-2.0.5.jar
如果我们用3.3覆盖它。 jar，常春藤会意识到它是错误的文件，并做一些像下载它的事情吗？
如果这不是一个选择，也许我们可以爆炸产生的战争，换掉战争，重新包装？
当然，如果liquibase供应的api发生了变化，那么这一切都将失败。
任何更好的建议都不涉及火箭科学？
我们最后的办法是完全放弃使用grails数据库迁移插件，并使用liquibase命令行手动完成所有操作，这非常繁琐。
不幸的是，我们不太可能改成grails 3。