Grails war command: what happens behind the scene

Question

I know that in Grails framework, you can build a war file using

grails war(builds a production war)

or you can build a environment-specific war file using

grails test war

Now, what I am having trouble understanding is, if I build a war file using grails war but deploy it to test environment (where -Dgrails.env=test), the war file built using grails war command runs happily by picking up **test ** environment settings(like pulling data from test urls instead of prod urls).

My question is: what is the point of building a war file using a environment-specific command (ie. why use grails test war when the war file built using grails war works everywhere?).

Am I missing something obvious?

Answer 1

The reason for using an environment is because you may code in your application that hooks into the build process and alters the resulting WAR based on the environment. Such as re configuring some filters in web.xml for instance. It's an extension point. You can use it if you need.

Answer 2

Grails holds three automatic environments: dev, test, prod. there are some defaults for the various "scripts", e.g. run-app runs dev, test-app runs test, war build a war for prod. these are there for convenience and make the most sense from the daily usage patterns for developers. e.g. in testing the default is an in-mem db.

You can also add more environments, as you see fit. E.g. having an staging or integration environment is common, so by providing such an env (maybe only some config or db changes) you can easily build a war file for the server you use for your QA team.

Another use case is to just build a dev war, as there might be something odd with the war on the production server and you just need to run the war against that odd tomcat 6.x real-life environment, but with the dev setting against your db.

That said, there still is the config you can add via config files, but the environments give a rather sane setup for "all involved", as they are usually within version control.

And as a final step you still have access to the environment in your own scripts/_Events.groovy hooks, where you might e.g. drop or add something, but that only makes sense for that exact environment (e.g. drop some jars, as they are on the server already).

At the end, this features gives you some freedom to do what you want. Be glad, if you never have to use it. But once you need, you'll be glad it's there.