Can I run database-migration plugin scripts outside Grails project?

I have been using the Grails database-migration plugin during development of my application, and really like its functionality. (Gr开发者_Go百科ails 1.3.7, database-migration 1.0)

The problem: I am constrained that all deployments must occur via Debian packages containing my application. It will be installed by another group who are competent admins, but not programmers in any sense of the word. Thus, it is not possible for me to migrate the database schema as indicated in typical workflow scenarios.

The question: What scripts/classes/??? do I need to bundle or depend on in the package to be able to execute the commands:

grails -Dgrails.env=$TARGET dbm-update

and

grails -Dgrails.env=$TARGET dbm-changelog-sync

and

grails -Dgrails.env=$PROD dbm-diff $PROMOTION_ENV

from my debian/postinst script?

I've tried installing Grails, making the database-migration plugin a runtime dependency, and including the Dbm* scripts... but haven't had success. The closest I've come is that Grails complains that I'm not in the root of a grails applicatoin when I attempt to run one of the scripts.

Can this be done, or can anyone provide a good alternative that hopefully won't cause me to need to learn a whole new migration metaphor?

Those three scripts are wrappers for the corresponding Liquibase actions. There are some Grails-specific scripts, e.g. dbm-gorm-diff, which creates a changelog between your code and a database, but that's a developer script that doesn't apply here.

So I'd go with straight Liquibase. The invocations are more verbose since you need to specify the connect information on the commandline (in Grails I can get that from the DataSource for you) but that should be easy to script. All you need is the Liquibase jar file in the classpath and that can also easily be added to the scripts.

The one other downside is that you'll be working in traditional Liquibase XML instead of Groovy-based migration scripts, so there's no looping, if/then checks, etc. But as long as you have fairly standard migrations to run it should be fine.

This is a different approach than using the plugin, but the plugin supports XML-based changelogs, so you can add changelogs generated in these scenarios to the ones you create (if that makes sense for your workflow).