JEE based projects with maven build artifacts like war or ear files is the cargo plugin the right choice for automatic deployments during the build process.

First step is to define in the build section of your pom.xml the cargo plugin:

	org.codehaus.cargo
	cargo-maven2-plugin
	1.1.4
	
		
			tomcat6x
			remote
		
		
			runtime
			
				
				${cargo.manager.url}
				${cargo.username}
				${cargo.password}
			
		
		
			remote
			
				
					${project.groupId}
					${project.artifactId}
					war
					
						${project.artifactId}
					
				
			
		
	

Notice the variables with the url and the credentials. The will filled with the used profile section for the build:

	
		tomcat6x_remote
		
			true
		
		
			http://ubuntu-vm.localdomain:8080/manager
			tomcat
			tomcat
		
	
	
		tomcat6x_ide
		
			http://localhost:9999/manager
			tomcat
			tomcat
		
			

The activeByDefault settings marks the remote section as default profile if nothing is set by command line parameters.

With

mvn org.codehaus.cargo:cargo-maven2-plugin:redeploy

you first undeploy the current application and then deploy the new build application to the remote tomcat instance. The command line parameter-Ptomcat6x_ide force maven to use the local tomcat instance for deployments.

mvn -Ptomcat6x_ide org.codehaus.cargo:cargo-maven2-plugin:redeploy

Hudson or Jenkins as continuous integration server can then be setup to use a primary project with the goal “clean deploy” to have a full test and maven repo deployment on success. The seconday project have the goal “clean package org.codehaus.cargo:cargo-maven2-plugin:redeploy -Dmaven.test.skip=true”. Inside the configuration of the primary job is the section with post build actions. Define here the secondary project to be build only on success of the primary build. Deployments can go wrong and should not have any effect on the primary build. Build trigger for the primary project is source code changes checked every minute (“* * * * *” as time plan). Changes by each developer force a complete junit and integration test of the module and new deployed artifacts inside the maven repo like nexus for the rest of the team. A little bit later is then the new application ready to use. With different profiles is it possible to define DEV,QA and PROD target server inside one maven project pom.

Tomcat needs credentials of a user with explicit rights granted for successful remote deployments. See the following excerpt of the tomcat-user.xml inside the conf folder of your tomcat instance: