automatically copy maven jars to target folder

[David Spades]

I'm wondering if it's possible for eclipse to copy all maven jars to certain folder during auto build (not maven build, but eclipse build, found in Project -> Build Automatically), just like we can configure eclipse to compile to java classes to target folder (by default, it will be bin, but can be configured to other folder as well). thanks

[Tim Holloway]

Why?

I've got something like 2GB of jars in my maven cache and a lot of them are different versions of the same thing, since different projects are at different resource versions.

One of the things I like about Maven is that it doesn't keep multiple copies of the same jar in multiple places. It pulls a copy from the cache when you do a build that needs it in the resulting product, and the rest of the time you're saving disk space.

[David Spades]

I didn;t mean all the jars in maven repository, but only jars included in a project (under maven dependencies). thanks

[David Spades]

basically I just need to know how to deploy my maven project to tomcat (all the compiled java source files, the resources, jsp, css, and javascripts including all jars in maven dependencies). So I need maven to delete the previous deployment (clean everything), and the redeploy in exploded form (not in war). Is there a plugin for eclipse to achieve this? thanks

[Tim Holloway]

You do not need to deploy your source code to Tomcat. Tomcat won't know what to do with it. You do need to deploy a WAR to Tomcat, and the easiest way to develop webapps using Maven+Eclipse is to layout your Eclipse project as a Maven WAR project, then add a Tomcat Context file to TOMCAT_HOME/conf/Catalina/localhost that has its codeBase pointing at the Eclipse project's target/xxxxxx.war file or the exploded war directory (xxxxxx) that is where Maven assembles the files that it will then pack into a WAR. Either one works, although you can save a few seconds if you skip the Maven goal that actually zips up the WAR.

To test such a webapp, stop Tomcat, run the maven goals "clean compile war:war", then start Tomcat. If your Context is properly defined, Tomcat will deploy the results of the Maven build and, if Tomcat is running in debugging mode, Eclipse will allow you to set breakpoints in your source code.

To make changes to the webapp, you should generally stop Tomcat, alter the code, re-run Maven and restart Tomcat. Tomcat can pick up changes on the fly, but complex projects may not re-deploy cleanly. One thing that usually is safe to do, however is change static (non-class) content on the fly. The command I use to do that is "mvn -o war:exploded".

The normal Maven war:war goal does not (re)compile the Java classes. The war:exploded likewise does not, and it also skips the actual zipping up of the WAR. The "-o" option tells Maven to run offline, which makes it a bit faster and is usually safe when doing lots of compiles one after the other. I do like to run online about once a day, though to pull any possible changes coming in from the archives.

[Tim Holloway]

By the way, I did make the assumption that you're running a local copy of Tomcat.

If you need to build a WAR and deploy it to a remote machine, there are Maven goals that do that using one of the several available remote deployment channels such as the Tomcat admin web services and the JSR-88 standard deployment mechanism. You'd have to define the target machine and deployment options in your POM.

[David Spades]

I'm running this:

mvn -o war:exploded

and my pom is:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.training</groupId>
	<artifactId>springtraining</artifactId>
	<packaging>war</packaging>
	<version>0.0.1-SNAPSHOT</version>
	<name>springtraining Maven Webapp</name>
	<url>http://maven.apache.org</url>
	<build>
		<finalName>springtraining</finalName>
		<pluginManagement>
			<plugins>
				<plugin>
					<groupId>org.codehaus.mojo</groupId>
					<artifactId>tomcat-maven-plugin</artifactId>
					<version>1.1</version>
					<configuration>
						<username>tomcat</username>
						<password>tomcat</password>
					</configuration>
				</plugin>
			</plugins>
		</pluginManagement>
	</build>
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.11</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-webmvc</artifactId>
			<version>3.2.5.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.springframework.security</groupId>
			<artifactId>spring-security-web</artifactId>
			<version>3.1.4.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.springframework.security</groupId>
			<artifactId>spring-security-config</artifactId>
			<version>3.1.4.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-jdbc</artifactId>
			<version>3.2.5.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-aop</artifactId>
			<version>3.2.5.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-tx</artifactId>
			<version>3.2.5.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>javax.servlet</groupId>
			<artifactId>jstl</artifactId>
			<version>1.2</version>
		</dependency>
		<dependency>
			<groupId>org.springframework.security</groupId>
			<artifactId>spring-security-taglibs</artifactId>
			<version>3.1.4.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>net.sourceforge.jtds</groupId>
			<artifactId>jtds</artifactId>
			<version>1.3.1</version>
		</dependency>
		<dependency>
			<groupId>javax.inject</groupId>
			<artifactId>javax.inject</artifactId>
			<version>1</version>
		</dependency>
		<dependency>
			<groupId>org.hibernate</groupId>
			<artifactId>hibernate-core</artifactId>
			<version>4.2.8.Final</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-orm</artifactId>
			<version>3.2.5.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>javax.servlet</groupId>
			<artifactId>javax.servlet-api</artifactId>
			<version>3.1.0</version>
		</dependency>
	</dependencies>
</project>

but nothing happened.
anything else I need to add?
thanks

[Tim Holloway]

What do you mean when you say "nothing happened"? Did it not create/update the exploded WAR in the target directory, or do you mean that your server didn't pick up the mods in real time or were the mods never picked up at all, even after a server restart?

[David Spades]

okay, clean project did the trick. but now, I got extraneous folder appearing in the deployment location. so here's what I did :
1. I saw that package com.springtraining.model should've been com.springtraining.hibernate.model
2. So, I right clicked on the package an refactor and change the name accordingly
3. when running mvn -o, I got two folders : the original com.springtraining.model and com.springtraining.hibernate.model, the former contains all files from the point before refactoring of the package, while the latter contains all the latest files from after refactoring of the package

I also couldn't resolve the maven-clean-plugin jar.

how do I resolve this?
thanks

[David Spades]

and I'm not behind any proxy. all other jars (spring and its dependencies are downloading just fine). I got this:

Failure to find org.apache.maven.plugins:maven-clean-plugin:jar:2.5 in http://repo.maven.apache.org/maven2 was cached in the local repository

[Tim Holloway]

If the command "mvn clean" is coming back with an error, then your copy of Maven may be damaged. That particular goal is pretty fundamental and is probably actually built into Maven itself.

When you run "mvn war:exploded", it does not do a clean, so if you change things, the original files in the target directory don't get wiped out, it's just that new target files get written. That will overwrite older copies of files, but not remove obsolete files, which is why I like to do my builds with a "clean" as the first goal in the list. Likewise, the "war" goals only assemble a WAR, they don't cause Java compiles, which is why my full build will be something like "clean compile war:war" or simply "clean package".

I make a distinction, because my builds are set up to construct an OS installer package, so "package" not only does the compile and war goals, but also the OS package builder goal, which I don't always want to run. Since most builds are for testing, not actual installation.

[David Spades]

thanks for the reply, what about the extraneous folder? and I've downloaded a new copy of maven, still got the same error regarding maven clean plugin. any idea? thanks

[Peter Johnson]

Regarding the error on mvn clean, try wiping out your local repository, or at least the org/apache/maven directory. It could be that the metadata in your local Maven repository is corrupted.