I have been using the Grails database-migration plugin during development of my application, and really like its functionality. (Grails 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).
Related
When I type generate-all, generate-controller or generate-vies, Grails current version (2.3.2) does not recognizes them. However, these commands remains on the Grails documentation. Does anyone knows if these commands were removed (and the docs are not up-to-date)?
Try grails compile first.
These commands are now part of the scaffolding plugin, and you might need to get grails to fetch the plugin
Grails 2.0.x ships with about a hundred third-party JARs -- ant, AspectJ, various things from Apache Commons, and so on. This is... good, I suppose?
But I want to use newer versions of some of those JARs, and when I try, I get various compatibility issues -- e.g., if I write a test using a Hamcrest class that was new in 1.2, I can, but at runtime I get NoSuchMethodErrors because the 1.1 Hamcrest core is ahead of it in the classpath.
I could of course just start messing with the grails-2.0.x/lib directory, but this seems like a bad idea and also means bypassing the normal Ivy / Maven way of specifying dependencies. (Oh, additional wrinkle: I'm using Maven for my Grails app, for interoperability with the rest of our codebase.)
So am I stuck with the Grails-distributed versions of these third-party JARs, or is there some way out of this?
I am relatively new to this and still bit puzzled how the Maven dependencies (in pom.xml) and the Grails dependencies (in BuildConfig.groovy) hang together.
When I choose Convert to Grails Project... in STS (Springsource Tool Suite) it seems to list the different (i.e. the Grails) dependencies.
Do I have to keep them in synch if I wanna receive a WAR file with mvn package/install? Sometimes I get weird build error and I am always unsure where to look for a fix.
Can anyone shed some light on this please?
Regards
Jonas
It sounds like you are using a mavenized grails project. See this bug report:
https://issuetracker.springsource.com/browse/STS-596
When working with a mavenized grails dependency you can work with a grails project, but make sure to turn off dependency management from right-click -> Grails Tools -> Disable Dependency Management.
There is not much tooling support for these projects since the STS grails tooling relies on calling grails to determine project structure and dependencies. But, when using maven, grails is not called directly and the Grails tooling is not initialized.
Background: I'm just learning Groovy and Grails. I inherited a project from someone who has disavowed themselves of it completely, so I'm basically just thumbing around blindly. I am using the Springsource IDE.
My source had a number of plugin dependencies. I attempted to install these via the plugin manager but one plugin (image-tools) was not available through that medium and needed to be installed separately. I've been unable to install it or the others, as I always end up with build errors which apparently reverts the partial plugin install. While search for references to the image-tools plugin which I could comment out in an attempt to get SOMETHING compiling correctly, I found the .link_to_grails_plugins directory, which seemed to contain the source of all the necessary grails plugins.
Adding this to my classpath and rebuilding seemed to let me make some progress, but I'm not sure if that's what I should actually be doing. Can someone explain to me what this folder is used for? Google hasn't been particularly helpful.
.link_to_grails_plugins is not a standard Grails directory - it has been created by the STS IDE.
The Grails plugins are cached in the grails.project.plugins.dir and grails.global.plugins.dir as described in the documentation for Customizing the Build:
The image-tools plugin documentation indicates that it must be built from the source and provides the instructions for doing so.
I need to set a different classpath for one single grails xxx command.
The point is that my application uses latest version of commons-httpclient. I have no problems with this. But after building my application I need to use grails maven-deploy to store my war file in a webdav repository, and the command conflicts with the latest version of commons-httpclient. This command works great if I add commons-httpclient-2.0.2.jar in the classpath (lib folder for example), but the app will fail on trying to use the regular features that depends on commons-httpclient.
I need to add this other jar in the classpath just for running the maven-deploy command, any ideas?
I'm using jenkins (huson) to build the app, so, any tips on making the solution achievable with grails jenkins plugins will be appreciated.
Thanks a lot,
Does the grails maven-deploy command conflicts due to another dependency on httpclient?
Which one is it? May be you could exclude the dependency it?