Don't bother with archetypes until later
For all information you need to know about Maven, have a read of some of the books on their website. 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)
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.