Cannot Generate XML Report From Maven Aggregate Goal

[stevespringett]

In previous versions of Dependency-Check Maven plugin, it was possible to generate the XML report during site. Now, executing site:site with format = all, will only generate the HTML report.

Generation of the XML aggregate report is necessary in order to process results by other systems - ThreadFix, Dependency-Check Jenkins Plugin, Dependency-Track, etc.

[stevespringett]

In the case of ThreadFix and Dependency-Track, these system do not care about modules, they care about applications. So aggregate reporting is necessary to satisfy the requirements of these systems.

[jeremylong]

Great... what did I break ;)

Steve - I'll try and figure this out. However, for users of the Maven plugin the aggregate report does not work very well - site:site works, but anything beyond fails (e.g. site:stage, site:deploy). The only thing I can come up with is requiring that the build be run twice (see issue #325).

--Jeremy

[jeremylong]

I love maven... So in my testing this can be fixed via configuration. The reporting section contains two places to supply configuration: in the plugin or in the reportSet. For the aggregate goal if you configure the plugin in the reportSet the configuration is ignored. Not sure why this is or how to read configurations from that section. So when configuring the plugin use the configuration at the plugin level:

    <reporting>
      <plugins>
            <plugin>
                <groupId>org.owasp</groupId>
                <artifactId>dependency-check-maven</artifactId>
                <version>1.3.6-SNAPSHOT</version>
                <configuration>
                    <format>ALL</format>
                </configuration>
                <reportSets>
                    <reportSet>
                        <id>dependency-check-aggregate</id>
                        <reports>
                            <report>aggregate</report>
                        </reports>
                    </reportSet>
                </reportSets>
            </plugin>
        </plugins>
    </reporting>

Does this solve the problem?

[stevespringett]

I'm on the otherside of the fence and despise Maven with a passion. And it's for reasons this like.

I have a very simple corporate pom. It has a dependency check profile

<profile>
  <id>dependency-check</id>
  <activation>
    <property>
      <name>env.ACTIVATE_DEPENDENCY_CHECK</name>
      <value>true</value>
    </property>
  </activation>
  <build>
    <defaultGoal>package</defaultGoal>
      <pluginManagement>
        <plugins>
          <plugin>
            <groupId>org.owasp</groupId>
            <artifactId>dependency-check-maven</artifactId>
            <version>${maven.dependency-check.plugin.version}</version>
            <configuration>
              <autoUpdate>true</autoUpdate>
              <format>ALL</format>
              <skipTestScope>true</skipTestScope>
              <cveUrl12Base>http://hostname/nist/nvdcve-%d.xml.gz</cveUrl12Base>
              <cveUrl12Modified>http://hostname/nist/nvdcve-modified.xml.gz</cveUrl12Modified>
              <cveUrl20Base>http://hostname/nist/nvdcve-2.0-%d.xml.gz</cveUrl20Base>
              <cveUrl20Modified>http://hostname/nist/nvdcve-2.0-modified.xml.gz</cveUrl20Modified>
              <suppressionFile>${env.DEPENDENCY-CHECK_SUPPRESSION}</suppressionFile>
              <externalReport>true</externalReport>
            </configuration>
          </plugin>
        </plugins>
      </pluginManagement>
      <plugins>
        <plugin>
          <groupId>org.owasp</groupId>
          <artifactId>dependency-check-maven</artifactId>
          <version>${maven.dependency-check.plugin.version}</version>
          <executions>
            <execution>
              <id>dependency-check</id>
              <phase>test</phase>
              <goals>
                <goal>check</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-site-plugin</artifactId>
        <version>${maven.site.plugin.version}</version>
        <configuration>
          <reportPlugins combine.children="override">
            <plugin>
              <groupId>org.owasp</groupId>
              <artifactId>dependency-check-maven</artifactId>
              <version>${maven.dependency-check.plugin.version}</version>
              <!-- After supplying this configuration, the XML report is generated
              without this configuration block, the XML report is not generated -->
              <configuration>
                <format>ALL</format>
              </configuration>
              <reportSets>
                <reportSet>
                  <reports>
                    <report>aggregate</report>
                  </reports>
                </reportSet>
              </reportSets>
            </plugin>
          </reportPlugins>
        </configuration>
        <executions>
          <execution>
            <id>dependency-check</id>
            <phase>site</phase>
            <goals>
              <goal>site</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</profile>

The idea is be flexible and simple enough (through standardization) to support the aggregate reporting using mvn -P dependency-check site or per module reporting using mvn -P dependency-check test

One objective was to be able to support the execution of the plugin using standard Maven lifecycles.

During site, I dont want to execute anything other than Dependency-Check, since that is the profile that's specified.

It appears however that when executing site, it ignores the configuration specified in plugin management. I would have liked to have one place to store configuration, but it appears that Maven is ignoring it and I can't think of another way to fix it other than to specify the configuration in two places.

[jeremylong]

Have you considered hosting an "internal" version of the maven plugin which has the configuration you are looking for? Here is an example I helped someone else with for using a central database (of course the properties at the bottom needed to be updated). Could likely hack together a similiar solution for your problem..

[jeremylong]

Oh, and regarding the comment about "loving Maven" - you missed the sarcasm tags.

[stevespringett]

:-) I'd rather not have a custom version of the plugin. With the number of DC releases we do a year, I wouldn't want to maintain this internally as well, since that process involves a lot of different groups to get involved. So is this a Maven problem or a DC plugin problem? It's really not clear to me.

[jeremylong]

Even the Maven documentation clearly states the configuration is separate for reporting plugins.

You could define all of the setting values as properties and then duplicate the configuration sections using the properties.

[stevespringett]

I ended up creating property values for each of the configurable items and duplicating the configuraiton sections. It's certainly not the most elegant approach, but it does seem to work.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.