Maven2 Web Application Setup: Legacy Step-by-Step Guide with Build, Jetty, and Site Reporting

Originally published on 2010-07-12; fully revised and updated.

This guide is for engineers maintaining or modernizing legacy Maven2-style Java web projects. You will learn how to bootstrap a project, switch to WAR packaging, run the core Maven lifecycle, use an in-place Jetty development loop, and generate project documentation and quality reports from pom.xml.

Create a Maven web application skeleton

The original workflow starts from the Maven archetype flow described in the Maven Getting Started Guide:

mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app

Then add web and resource directories for a typical JSP/Servlet style project:

mkdir -p my-app/src/main/webapps/WEB-INF
mkdir -p my-app/src/main/resources
mkdir -p my-app/src/test/resources

To produce a web archive instead of a JAR, change packaging from jar to war. The original post also configured the compiler for Java 1.5:

<packaging>war</packaging>

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <configuration>
        <source>1.5</source>
        <target>1.5</target>
      </configuration>
    </plugin>
  </plugins>
</build>Code language: HTML, XML (xml)

Core Maven goals you will use daily

# Common local build sequence
mvn clean test packageCode language: PHP (php)

Run an in-place development loop with Jetty

The original article uses the Maven2 Jetty Plugin to run the app directly from source and shorten edit-build-run feedback cycles.

flowchart LR
    A[Create project] --> B[Add web directories]
    B --> C[Set packaging to war]
    C --> D[Run clean test package]
    D --> E[Start Jetty]
    E --> F[Open app in browser]
    F --> G[Edit code]
    G --> D
    D --> H[Generate site reports]

Legacy Jetty configuration snippet from the original workflow:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>maven-jetty6-plugin</artifactId>
  <configuration>
    <scanIntervalSeconds>10</scanIntervalSeconds>
  </configuration>
  <dependencies>
    <dependency>
      <groupId>org.apache.geronimo.specs</groupId>
      <artifactId>geronimo-j2ee_1.4_spec</artifactId>
      <version>1.0</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>
</plugin>Code language: HTML, XML (xml)

mvn jetty6:runCode language: CSS (css)

Expected local URL in this setup: http://localhost:8080/my-app.

Generate IDE metadata from pom.xml

The post highlights Maven-driven IDE metadata generation so source paths and dependencies come from the same POM definition.

mvn eclipse:eclipseCode language: CSS (css)

It also notes setting M2_REPO in Eclipse to point to the local repository path (typically ~/.m2/repository).

Build project documentation and reports with Maven Site

Maven can generate a project site and reports from POM metadata and source docs. The original article references DocBook, APT (Almost Plain Text), and FML for FAQ content.

mkdir -p my-app/src/site/apt
mkdir -p my-app/src/site/fml
mkdir -p my-app/src/site/resources/images
touch my-app/src/site/site.xml

mvn site

The original Cobertura notes mention that a cobertura.ser file may be left in the project root and can be removed with mvn clean.

Original reference links

• The Maven 2 POM demystified
• Get the most out of Maven2 site generation
• The Maven2 Schema
• Better Builds with Maven
• Maven : A Developer’s Notebook
• Checkstyle
• Cobertura
• Cobertura Maven plugin

Best practices and common pitfalls

• Treat this as a legacy Maven2 baseline; validate plugin goals and coordinates in your current Maven environment.
• Keep build logic centralized in pom.xml so IDE, CI, packaging, and documentation use the same source of truth.
• Run mvn clean test frequently to catch classpath and test breakage early.
• If you rely on mvn site, keep reporting plugins intentionally curated to avoid noisy or stale reports.
• Document your project conventions (directory layout, Java level, plugin set) in-repo so onboarding does not depend on tribal knowledge.
• For deployment transport (Wagon and related flows), add explicit environment-specific documentation because the original post does not provide implementation detail.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.