We Keep Coding

Grails war command: what happens behind the scene

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?

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.

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.

java maven how to create app with bundled tomcat

I wonder if this is a somewhat awkward way of thinking, but I couldn't really find any hint on the internet to my idea. Maybe I just did not phrase my question right, but anyhow, this is what I would like to do:
I have a complex application written in java with spring and quartz and a whole load of dependencies. The application is run inside an apache tomcat servlet container. Now I know, I can create a war file and deploy that to the productive server machine (after our internal IT has installed and configured the tomcat on that machine), but I would like to do this a bit different.
I would like maven to create a pre-packaged tomcat application server with all dependencies and configuration settings AND my application. In effect, all that would need to be done on the productive system is, copy the package (or zip or tar.gz or whatever is needed) to the server, unpack it in a directory of my or their choice and fire up this local isolated tomcat. It would only run my application (which poses enough load on the machine anyway) and I could even go so far and deploy a second variant, say for a different customer in the directory next to the first one. Neither of both could interfere with each other, even if they use different versions with different dependencies.
Is it possible to do that? Is it a desirable approach or am I on the completely wrong track here?
What I think would be a benefit of this approach (despite the thing with incompatible dependencies or settings between two or more different installations) is, that I can hand the whole package over to our administration guys and they can simply deploy it to a server without the need to configure anything in the tomcat after installing it and so on.
Any hint???

Create a Maven project as the parent project (type pom). Include your webapp as a module project (type war). Create another module project, maybe "myapp-standalone" (type jar) and include the Embeddable Tomcat as a dependency. Write a starter class to launch the internal Tomcat (see executable jar / überjar). When building the app, copy the created war file into the jar, into Tomcats webapp directoy.
Your launcher class needs to make sure, that the ports of the current Tomcat are not yet in use.

Hot-deploy JSPs in web-fragment using Eclipse and Tomcat (Servlet 3.0)

I have a project set up like this:
/parent
/core
/src/main/
/resources/META-INF/
web-fragment.xml
/resources/jsp/
fragment.jsp
/java/
FragmentTest.java
/web
/src/main/
/webapp/
/WEB-INF/web.xml
/jsps/
parent.jsp
/java/
ParentTest.java
the 'core' compiles to a .jar within the .war.
However, when deploying this to Tomcat, with debug enabled, I can edit parent.jsp and it will hot deploy, however if I update fragment.jsp then it will not, and I have to rebuild/redeploy/etc.
However, any changes to the .java in either project will hot-deploy successfully.
Is anyone aware of any configurations, etc. that may be missing to get web-fragment JSPs to hot deploy?
Thanks!

I have the same situation. I have test-web (your parent) and test-web-fragment (your core). I resolved them in the following way:
In the /test-web -> Properties -> Deployment Assembly I added the Fileset rule that points to /test-web-fragment/src/main/resources/META-INF/resources (See the screenshots below).
When I change something in a page from fragment, the eclipse builder copies it to /test-web/src/main/webapp. After that I do a right click to test-web in app server and click Full Publish and I have to the server my changes. This trick I use in the development mode. When I make the build for production I use maven, without this rule.

Your project structure confuses me a bit. We always place JSPs in /src/main/webapp and sub folders therein. I can very well imagine this to be the source of your problem.

You will be able to hot deploy both JSPs and Java files if you do the following:
Separate your web fragment project into two different projects and reference them from your main Web applications:
One containing all your Java source files (this project has to be a Web Fragment). This will be packed as a JAR file and you will be able to hot deploy Java files as you're currently doing
Another project, a Dynamic Web Project, containing all your static / JSP files under the WebContent folder. This will be deployed unpacked and will allow you to hot deploy everything under WebContent folder
There could be a better option than this one, but at least you will be able to work properly until you find something better.

Correctly Deploy maven project

I have a project with maven, this a multimodule project
Mainproject
project1 - jar
project2 - jar
project3 - web
Now that I finished the project I want to test it on the server but don't know how to upload them, on my computer I have added a plug for tomcat which deploys the war file to tomcat automatically, but the server doesn't have maven.
What is the way for moving to production with this kind of projects?
Should I just upload the target directories for each module?
Thanks

You're asking a few questions here. There is the "how do I test on a server" one, and there is "what is the way for moving to production" one. And they can be quite different.
I have assumed that the JAR files in the project are used by the WAR file and packaged within its WEB-INF/lib directory. If I'm wrong, that's cool. Just this sort of information is handy to know.
Maven is a build tool. It is not a deployment tool. What you have at the end of this, is a WAR file. If you run mvn install (or mvn deploy) you have a SNAPSHOT version of the WAR file. This would be suitable for quick, ad-hoc testing to other machines. But you would most likely use methods approriate for the hosting container for making them available. Note: a Maven DEPLOY is a different thing from a DEPLOY a war file to tomcat.
To my mind, if you're putting anything into production, or in front of a customer, or in front of a testing group, you should use Maven to make a Release of the product. That is, using the release plugin (via the release:prepare and release:plugin goals) to create a non-SNAPSHOT release of your artifact (in this case, a official version of the WAR file). Once you have that WAR file, you can migrate it to your production server in whatever way is easiest (copy, deploy into tomcat in the best way). You haven't mentioned if there are database requirements for this web application, and that would need to be considered before you change any production application.
But, once you have official versions, you have tags of source code, and you can accurately know what code is being run.
What I don't think you're going to get is being able to automatically copy the WAR file into a production server from your development environment. Here be dragons.

Multiple configurations of the same war

Currently, I have a web application, export it with eclipse in a war, copy it manually with scp on the server, run a script that extracts the war, uses local configuration files to overwrite the ones in the war, and copies the extracted folder in tomcat/webapps. This sounds easy for a server or two, but not for 100.
How can I improve this, in order to have better control of the versions/configurations installed and to deploy it more easily?

You could really benefit from using Cruise Control, or Hudson to do continuous builds for you. In there you can have the war-local configurations built into the war. You could build many flavors of these. Then, to deploy, it's just a matter of pushing the proper wars to their rightful place. No exploding, rewarring required.

See Deploy web application on multiple tomcat servers with Kwatee Agile Deployment. Once you have configured the deployment parameters with the web interface you could trigger from Ant using the kwatee task or from a continuous integration tool with the python CLI tools.

To help manage these multiple configurations, I have programmed a very lightweight library named xboxng here
It is flexible and pretty easy to use (no need for JNDI).

Store the specific configuration files of each server in a directory, put these under version control, and use something like Ant to take a "naked" war, unzip it, replace the files with the config files of the server you want to deploy to, and rebuild the war.
Then scp the war to the server directly. This can also be done using ant.
configs
- server1
- file1.properties
- file2.xml
- server2
- file1.properties
- file2.xml
ant -Dserver=server2 war deploy

As this is not a single answer question, depending on the project and, why not, personal taste, I will post some the steps I believe could help the whole process of management/deployment.
This does not mean that the solutions offered by the other posters are wrong (some of them received my upvote), but that this is what I found will work better for me.
1) In order to have only one version of war with multiple configurations, I used JNDI. I set up a env variable to the path where I could find the config. This was added to web.xml:
<env-entry>
<description>path to configuration files</description>
<env-entry-name>appName/pathToConfigFiles</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>/configFolder/appName/</env-entry-value>
</env-entry>
This has a default value, when the config files are taken from the war, but it can be overriden by context.xml.
<Environment name="appName/pathToConfigFiles"
type="java.lang.String" value="/etc/.."/>
This way if someone needs for example to change the database connection parameters I will not have to deploy a new war. The admin can change the file in the configuration folder.
The db config file and log4j file are my only external files. The rest of the configuration is done through the database.
Main advantage is that the same artifact can be deployed both in testing and production and on any of the 100 servers. I currently use it on Tomcat, but env variables should be available in other app servers.
2) Changed from an IDE build to a build-tool. I chose maven, but you can use ant/whatever.
For this I found useful the following sources:
"Maven by Example" book;
M2Eclipse plugin
For this I will also need to install Nexus as a mirror repository.
3) Install a continuous integration tool like Jenkins/Hudson. It is a wonderful tool, but because of its complex nature, it will take time to configure it and increment it's functionality. I am currently reading Jenkins: Definitive Guide, and I am trying to obtain the following functionalities:
Automated build server
Automated junit test server
Adding metrics
Automated test env deployment and Acceptance Testing
Continuous Deployment
Until this will be accomplished the wars will be deployed through bash scripts. I just scp the war to the server (no exploding/rewarring).