Take the 2-minute tour ×

I've been developing Java EE web apps with Eclipse for about a year. My employer doesn't use Maven, but the more I read about it, the more convinced I am that Maven + Hudson will be greatly beneficial for us. First, though, I have to become comfortable with those technologies in my spare time, so that I can create a proof-of-concept.

Right now, I'm still a Maven newbie. Is there a set of best practices for creating Java EE web apps with Maven? For example, I could create a project with a basic archetype and then add all of the necessary JARs by putting dependencies in the POM for the servlet container, EJB, EclipseLink, etc... That might work, but it might not be the best way to do it. I'd greatly appreciate any guidance that you could provide on this topic.

share|improve this question

5 Answers 5

up vote 6 down vote accepted

Don't bother with archetypes until later

For all information you need to know about Maven, have a read of "Better Builds with Maven" (PDF). However, that's a bit of overkill for what you're trying to achieve.

To get started, lay out your web application following the standard Maven structure for web apps as follows. (You don't need a Maven archetype for this, it's just a bunch of standard folders, you can make it in 2 minutes).

  • src/main/java - contains your production Java code
  • src/main/resources - contains your production classpath resources (e.g. Spring contexts)
  • src/main/webapp - (contains WEB-INF/web.xml but no lib folder)
  • src/test/java - contains your test Java code
  • src/test/resources - contains your test resources (e.g. example XML feeds for web service testing etc)

Basic plugins

The next step is to choose a bunch of plugins. The usual suspects are, obviously the ones supporting clean, compile, and resources (come as part of Maven but you can configure them). Then you'll have the surefire unit tester and the WAR plugin. That's enough to create a very basic web application.

More advanced plugins

The next step is to introduce Findbugs and PMD plugins which will give your code a thorough going over and report various potential issues. You probably will want to have JXR for cross-referencing source code, taglist for tracking TODOs and REFACTOR tags and so on. Above all...

...Use the Jetty plugin for web applications

Use the Jetty plugin to run up your WAR file within your IDE for easy debugging. It's fast and small and gets the job done real quick. Having Jetty as part of your Maven build makes your project able to be tested on any machine without needing an IDE with some complex Servers panel configured. It also allows you to declare dependencies on other WAR files which in turn means you can generate a complete working environment consisting of multiple web applications all with a single command "mvn clean jetty:run". This works anywhere, and you can even provide a test JNDI configuration so your Spring-injected data sources are all externally configured. If you combine this Jetty approach with a standard demonstration HTML page (src/test/resources/demo.html) you'll save oodles of developer hours trying to get a working local environment. One command and you're done. Simple.

Configuring your IDE

With Maven it's easy since all the big boys support it: Eclipse, Netbeans and, of course my personal favourite Intellij. Just point your IDE at the pom.xml and it'll take care of bring down all the listed dependencies for you. No more mucking about with WEB-INF/lib. In Eclipse, you typically use File | Import... | Maven Project | pom.xml.

Integrating with Hudson

First install Hudson (it's just a webapp) and then target your version control system so that it checks out the appropriate version. Your final step is to configure it so that it uses Maven to do the build. Obviously Maven will have to be installed on your build machine (assuming it's different from your development machine).

Hudson does the snapshot builds only

Have Hudson perform snapshot builds, and leave release builds to a manual process. Using that approach will mean that developers can share their code under a snapshot revision (e.g. 1.0.0-SNAPSHOT) and only if it is able to pass the build will it be shared into the team repository. Typically, Hudson will execute "mvn clean deploy" although including the "site" goal may also be part of your process since it'll create a small project website for every build. Developers on the team will have the updated snapshot build automatically included into their project through the Maven dependency management process.

Hudson provides a wealth of plugins that can support all manner of metrics. My personal favourite is to keep track of the number of passing tests per project over time. It's great to show management that your unit test count and coverage is ever increasing.

General setup guidance

Split your repositories into at least the following structure:

  • team-release - All your released production artifacts go here
  • team-snapshot - All your snapshot development artifacts go here
  • third-party-release - All your supporting third-party libraries go here (e.g. Spring, Hibernate etc)

Developer user accounts should not be able to write to the team repositories, either snapshot or release. This would enable a developer to bypass Hudson if they're in a hurry and will quickly become the norm.

Make sure you always download the source, javadocs and SHA signatures for all your third parties. Jarvana is an excellent repository explorer for all those hard to find classes.

Consider installing a repository manager like Nexus or Artifactory to allow better control over your ever-growing repository.

share|improve this answer
Sonar is also pretty awesome and fits well with maven/Hudson –  Kevin Jul 5 '12 at 3:16
Absolutely. Right now, if I'm working on a Maven project in a team I'd expect a local Findbugs/PMD to catch the killer problems fast, then a Sonar job after a Jenkins build with artifact deployment to Nexus or Artifactory. This provides easy location of artifacts, and provides impact analysis ("where used") for those artifacts throughout the project ecosystem. Coupled with git, JIRA and Fisheye you've got an awesome development process available to you. –  Gary Rowe Jul 5 '12 at 8:14

Maven provides plenty of of archetypes

mvn archetype:generate

will print a list of available.

The main difference between plain Java archetypes with J2EE archetypes is that directories for jsp and images will be generated. If you starting a new J2EE project consider using one of them from the beginning.

As your project grows you may add more dependencies. Personally I prefer to start with minimal collection of dependencies (eg J2EE basic archetype) and then gradually adding what I need.

share|improve this answer

I've done it by starting from a basic archetype and adding in all the bits, and I'm fairly sure that that's not a very good way. But I find it's awkward the other way too; selecting what is a good archetype is difficult unless you're already “deeply versed in the secrets”. That's all a little bit too much like wizardly lore (as opposed to sensible discoverable technical information) for my taste…

share|improve this answer
And I think it's a good question. Wish I had a better answer. –  Donal Fellows Mar 6 '11 at 16:24
It's very much appreciated, sir. –  M.C. Mar 6 '11 at 17:12

Maven provides a way to create projects from templates called Archetypes. You use the command mvn archetype:generate to pick one interactively. You can also specify one directly.

mvn archetype:generate \
    -DarchetypeGroupId=org.apache.maven.archetypes \
    -DarchetypeArtifactId=maven-archetype-j2ee-simple \

All on one line.

share|improve this answer

I have been using Maven and Hudson last three months. It helps me to check the health of the code base regurally by executing all unit tests, generating test report. You can try this.
You can also try Spring Roo. It is a RAD tool for creating Spring based J2EE project.

share|improve this answer

Your Answer


