Maven Reporting Plugins: Configure Site Reports in pom.xml (All, Selective, and reportSets)

Originally published on 2010-04-14; fully revised and updated.

Maven reporting plugins generate project documentation (such as project metadata, test summaries, source analysis, and API docs) during the Maven Site lifecycle. This guide is for DevOps and build engineers who want to configure reports correctly in pom.xml, run all reports or only selected reports, and avoid common configuration mistakes.

The original post also included a YouTube gallery embed that currently fails with an API-key restriction error; the referenced setup video link is here.

What Maven reporting plugins are

Reporting plugins are configured under the <reporting> section and are executed as part of site generation. In practice, you typically run mvn site (or the older form mvn site:site) and Maven writes report output into target/site.

mvn site
# legacy invocation often seen in older docs
mvn site:siteCode language: CSS (css)

Reporting section vs build plugins section

The source article highlights an important distinction: configuration placed in <reporting> is intended for report generation, while configuration in <build><plugins> is intended for build lifecycle goals. Treat them as separate concerns.

Report generation workflow in the Maven Site lifecycle

flowchart TD
    A[Configure reporting in pom.xml] --> B[Run mvn site]
    B --> C[Site lifecycle executes]
    C --> D[Reporting plugin goals run]
    D --> E[HTML reports generated in target/site]
    E --> F[Publish or archive site artifacts]

Configure all Project Info reports

To include the default report set from the Project Info Reports plugin, add the plugin under <reporting>:

<project>
  ...
  <reporting>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-project-info-reports-plugin</artifactId>
      </plugin>
    </plugins>
  </reporting>
</project>Code language: HTML, XML (xml)

mvn site

Run selected reports only

The original article shows selecting reports explicitly. The example below mirrors those legacy report names from the source post:

<reporting>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-project-info-reports-plugin</artifactId>
      <reportSets>
        <reportSet>
          <reports>
            <report>dependencies</report>
            <report>project-team</report>
            <report>mailing-list</report>
            <report>cim</report>
            <report>issue-tracking</report>
            <report>license</report>
            <report>scm</report>
          </reports>
        </reportSet>
      </reportSets>
    </plugin>
  </plugins>
</reporting>Code language: HTML, XML (xml)

Configure multiple reports for one plugin with reportSets

You can define multiple report sets for one plugin. As noted in the source material, each <reportSet> should have a unique <id>. The following preserves the original UMLGraph-style Javadoc example pattern:

<reporting>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-javadoc-plugin</artifactId>
      <reportSets>
        <reportSet>
          <id>uml</id>
          <configuration>
            <doclet>gr.spinellis.umlgraph.doclet.UmlGraph</doclet>
            <docletArtifact>
              <groupId>gr.spinellis</groupId>
              <artifactId>UmlGraph</artifactId>
              <version>4.4</version>
            </docletArtifact>
            <additionalparam>-views</additionalparam>
            <destDir>target/uml</destDir>
            <show>private</show>
          </configuration>
          <reports>
            <report>javadoc</report>
          </reports>
        </reportSet>

        <reportSet>
          <id>api</id>
          <reports>
            <report>javadoc</report>
          </reports>
        </reportSet>
      </reportSets>
    </plugin>
  </plugins>
</reporting>Code language: HTML, XML (xml)

Known plugins that provide reports (legacy links from the original post)

Common pitfalls

• Placing report configuration only under <build><plugins> and expecting mvn site to use it.
• Copying legacy report names without validating against your current plugin version.
• Forgetting project metadata sections (SCM, issue tracking, organization), which can make reports incomplete.
• Using old plugin URLs and version references from historical posts without checking current documentation.
• Generating reports locally but not publishing target/site artifacts in CI/CD.

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.