Is there a way to specify the directory in which Grails looks for domain classes? I want to have grails enhance domain classes from grails-app/domain as well as test/domain, when running in the test environment.
The reason I need this is that I have some domain classes which I use in a plugin for integration tests. They currently sit in grails-app/domain under a specific package. In the plugin descriptor I ensure that this package is excluded from the plugin build. This works fine when it is packaged as a plugin, however for various reasons we run and build our app with this plugin declared inline in BuildConfig.xml. This causes those domain classes to be compiled into the host application, despite the exclusion declared in the plugin descriptor - so they are deployed with the application and tables are generated for them, which I don't want.
Any ideas?
Thanks.
Related
I'm writing a custom Grails 2 plugin to modularize my Grails applications. In the plugin I'm planning to define basic GSPs that can be overridden by the application that will utilize the plugin. I'm thinking of writing a Grails command script that copies those GSPs into the grails-app directory of the app the plugin is installed in. If in the plugin, I put those GSPs in grails-app/views, how do I refer to the actual Grails app directory in the Grails command script, which is also grails-app/views?
The solution to this is almost the same as this answer. The built-in properties basedir and <plugin_name>PluginBaseDir differentiate the target app and the plugin directories.
I've got a list of grails plugings in my 1.3.7 app.
I'm converting it to 2.1.0 and doing a cleanup.
In my application.properties I have the following:
plugins.build-test-data=2.0.3
plugins.fixtures=1.1
plugins.hibernate=2.1.0
plugins.pretty-time=0.3
plugins.mail=1.0
plugins.quartz=0.4.2
plugins.spring-security-core=1.2.7.3
plugins.tomcat=2.1.0
I'm moving them all to my BuildConfig.groovy instead.
I'm curious as to what is the most appropriate scope for each plugin?
Thanks
My usual rule of thumb is
build scope for plugins that are part of the build process but shouldn't go into the WAR for production deployment
test scope for things that should be available to tests but not to application code
runtime scope for plugins (or JAR dependencies) that you need for the app to run but which you don't want to tightly couple your app to (you can't import a class from a runtime dependency into one of your app's own classes, for example)
compile scope for everything else
If in doubt, compile will definitely work, as plugins in application.properties are treated as if they were declared in compile scope.
So tomcat definitely wants build scope, spring-security-core definitely wants compile, I guess fixtures and build-test-data should be test, the others compile or runtime depending on whether you need to import any of their classes directly.
I am working with a (sort of) framework built on top of Grails. This framework is a set of Grails plugins that add functionality to the Grails app (e.g. user authentication). This framework is a bit of a pain to setup, as it requires around 64 lines of site specific configuration in the apps's Config.groovy file.
I want to develop my addons to this app as plugins. That is, the Grails app would really just be a set of installed plugins and some configuration files.
I have created a local Maven style repository to hold all of my plugins. Thus, I can add plugin dependencies to the BuildConfig.groovy file and they will be installed automatically (side question: is it possible to specify the install order?).
So my question is, how do I create skeleton project for developing my plugins that would:
Include the base configuration for my application (the aforementioned 64 lines)
Allow me to do a grails package-plugin to package only the plugin's code
You can use the post-installation hooks mechanism: http://grails.org/doc/latest/guide/plugins.html#hookingIntoBuildEvents
Not really an ideal setup for me, but the following works:
Create the "base" application: cd ~/GrailsDev/ && grails create-app my-app
Configure my-app as desired/required
Create your dependent plugin: cd ~/GrailsDev/ && grails create-plugin my-app-plugin
Add the new plugin to the app by editing "~/GrailsDev/my-app/grails-app/conf/BuildConfig.groovy" and appending the line: grails.plugin.location.'my-app-plugin' = "../my-app-plugin"
You can now run the my-app Grails application and the plugin will be included. When your plugin is fully developed, you can do grails package-plugin from within the "~/GrailsDev/my-app-plugin" directory to package your plugin.
use gradle. you can specify the order and package your plugin alone.
e.g. include the required plugins as git modules (for easy versioning) and gradle modules (for building your plugin) in your plugin project.
this setup will serve your requirements well I suppose.
https://github.com/grails/grails-gradle-plugin
IntelliJ does have a template for gradle-backed grails applications and plugins.
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).
I've got a Tomcat6 server that runs multiple Instances for two separate grail apps.
When I compile my WAR file for deployment normally
run-app -Dgrails.env=production war test.war
It deploys correctly and everything works as it is suppose too.
The problem is, I don't want the JAR files included in my WAR.
So I use the following command line instead
run-app -Dgrails.env=production war test.war --nojars
Now when my grails app deploys (it doesn't) I get a java.lang.NoSuchMethodError
I have copied the lib folder (from my initial test.war) to the following locations
${catalina.base}/shared/lib
${catalina.home}/shared/lib
${catalina.home}/lib
None of these work.
My catalina.properties all point to the correct locations.
Any ideas?
A few ideas:
BuildConfig.groovy has inherits global, which has the app inherit all of the grails/plugins dependencies. If you change this, it may affect both your build and packaging - plus I have yet to encounter any documentation on what type of other things you can do with the inherits DSL
Grails deployment documentation suggests there is a way to customize which dependencies make it into the war file: http://grails.org/doc/latest/guide/17.%20Deployment.html
Event hooks give you access to provide a closure routine into various stages of the grails lifecycle. Can it strip out framework jars from the final war? Haven't tried that either - only using it to re-write various config files for additional envrionment configuration. However it does look like packaging events are exposed to this API:
http://grails.org/doc/latest/guide/4.%20The%20Command%20Line.html