I would like to use certain plugin in development environment, but would like to exclude this plugin from production and from generated war. What is the easiest way to accomplish this?
Yes, using plugin scopes. From http://grails.org/1.1+Release+Notes:
Plugins can now be scoped using either the environment or predefined build scopes:
def environments = ['dev', 'test']
def scopes = [excludes:'war']
The plugins will only load in those environments and will not be packaged into the WAR file. This allows "development-only" plugins to not be packaged for production use.
I don't believe that there is a way to achieve this without editing the plugin itself (as Jean pointed out)
If you have control over the plugin then that will work, but if you just wanted to configure this as you were 'using' it, then you will need to copy and run a patched version of the plugin with your modifications. You'd customizing it by utilizing a custom location for that plugin in your grails-app/conf/BuildConfig.groovy file.
If you want to exclude the plugin in certain environment, you need to do this:
runtime (':plugin:version') {
if (Environment.current == Environment.PRODUCTION) {
export = false
}
}
You can use the excludes property in your config.groovy:
production {
grails.plugin.excludes='console,classDiagram'
}
But there seems to be some confusion as to if it will exclude it from both 'run-app' and 'war'. I will try to check today and verify
Related
I'm close to giving up here -- there's roughly 5 different repositories with different versions of handlebars-asset-pipeline with different instructions, and I can't get any of them to work.
I'm using Grails 3.1.1 with the default build.gradle created by init-app, added handlebars-asset-pipeline 2.7 to both the buildscript and normal dependencies, and put a foo.hbs file into grails-app/assets.
Now, when running gradlew compileAssets, the templates get compiled correctly, so the plugin is doing something, but I was expecting it to also work when running the application via grails run-app. Is it wrong of me to expect that? If not, can someone be so kind as to give me a working example of how to integrate the template precompiler?
I find specifying assets instead of runtime is the thing that trips me up. I can get it to work adding the following
buildscript {
...
dependencies {
...
classpath "com.bertramlabs.plugins:asset-pipeline-gradle:2.14.6"
}
}
apply plugin: 'com.bertramlabs.asset-pipeline'
runtime "com.bertramlabs.plugins:asset-pipeline-grails:2.14.3"
assets 'com.bertramlabs.plugins:handlebars-asset-pipeline:2.14.6'
I don't use it but since you use Gradle I'm quite sure you can add it as your own task with dependsOn: 'compileAssets'. Check out example for Android.
Does Grails 3.0.x no longer have the ability to create wrappers anymore?
The documentation doesn't seem to have the Grails wrapper section anymore.
Is there an alternative way which we can use the gradle wrapper to execute grails commands such as create-controller?
Does Grails 3.0.x no longer have the ability to create wrappers
anymore?
No.
Is there an alternative way which we can use the gradle wrapper to
execute grails commands such as create-controller?
Not for commands like create-controller, no.
We may re-introduce grailsw. File a feature request at https://github.com/grails/grails-core/issues if you would like to track that.
The Grails wrapper is back as of Grails 3.2.3:
http://docs.grails.org/3.2.x/guide/introduction.html#whatsNewGrailsWrapper
I have an app created with Grails 3.1.x, then upgraded to Grails 3.2.6, but the files such as 'grailsw' did not appear in my project root, and I'm not sure how to get them added via some command in the project.
When I create a new app using Grails 3.2.6, the new files are in the project root (grailsw, grailsw.bat, grails-wrapper.jar). I assume they can be copied over to an app like mine: a quick test of this worked for me.
Grails allows you to define different "environments" for your app inside Config.groovy like so:
environments {
development {
...
}
demo {
...
}
production {
...
}
}
Thus you can run your app like so:
grails -Dgrails.env=demo run-app
...and Grails will run your app in "demo" environment mode. The default is development, so if you just execute:
grails run-app
...it's the same as:
grails -Dgrails.env=development run-app
However I was wondering if it is possible (and if so, how) to override development as the default and make it, say, demo? Such that:
grails run-app
...is equivalent to:
grails -Dgrails.env=demo run-app
Thoughts?
However I was wondering if it is possible (and if so, how) to override development as the default
No, this is not possible. Incidentally, the default environment depends on the command, e.g.
the default environment for run-app is development
the default environment for test-app is test
the default environment for war is production
The short answer is no (or at least it is not documented and I wasn't able to make it work), but the slightly longer answer is that even if you could you probably don't want to.
By changing the default environment you'll create an additional barrier to entry for new developers and are likely to have quite a few "oh damn, it doesn't run in dev by default, of course" moments.
It's also worth noting that while the development is the default for run-app, test-app defaults to test and war defaults to production.
The development environment is just a label, so if you really wanted to use it for something else (such as demos), you could just create a separate actualDev environment, but again it's likely to cause confusion in the distant future when everyone's forgotten it's set up like that.
Okay, but what can I do to make demos easier?
I've always made use of the /scripts/ directory in the standard Grails structure to ease setup and demo overheads, so you could create demo.sh for demos, which would also let you setup/teardown any other resources if/when your application becomes more complex and interconnected.
I'm trying to create a grails app that has no database/hibernate/gorm/datasource configuration. In Rails, I can create a new app with the '--skip-active-record' command which will let me create controllers/models/etc without any database concerns.
I'm needing this because my controller just makes a couple rest calls and returns a result so there's no need for the database.
Is this possible? I saw Can I configure Grails with no datasource? but it seems to not work with Grails 2.3. I get this message: "To remove a plugin, delete it from BuildConfig.groovy and/or application.properties."
Is this possible? Thanks
The uninstall-plugin and install-plugin commands were deprecated in 2.2 and removed in 2.3.
To remove a plugin, delete it from BuildConfig.groovy and/or application.properties.
So you can just remove the hibernate plugin entry from BuildConfig.groovy. You probably also need to remove the cache plugin, and you should remove the database-migration plugin since you won't need it.
I have been developing several Grails applications over the past couple of years. I am increasingly finding that the three grails environments (dev, test, prod) aren't enough to satisfy my needs. The more "enterprisey" your application gets, the more environments you tend to have.
I tend to use 6 environments for my development cycle...
DEVA //My dev
DEVB //Team mates dev
CI_TEST //CI like Hudson
QA_TEST //Testing team environment
UAT_TEST //Customers testing environment
PROD //Production
Im wondering if there is a way to define custom Grails environments? I dont think there is, but the feature could be handy.
The way I am getting around this right now is by externalising the config to a properties file.
Id imagine that this is a pretty common requirement, so how have you been dealing with your environments?
Config.groovy and DataSource.groovy both support custom environments (I'm pretty sure most other config files do as well).
If you want to start up your app or package it for a custom env you use
grails -Dgrails.env=myCustomEnv run-app
Then in Config you would have
environments{
myCustomEnv{
myProp = 'myVal'
}
}
I couldn't find a page in the user guide about it but we use them like this to have beta and uat environment settings.
One option could be to define a dataSource in DataSource.groovy for each of your environments and then store configuration information in the database.
You could then add code in BootStrap.groovy to load your configurations.