Joaquín Cañadas <jjcanada@ual.es>

Maven es una herramienta de construcción y gestión de dependencias para proyectos Java. Maven se encarga de la gestión del ciclo de vida del proyecto, incluyendo la compilación, la ejecución de los test, la generación de documentación, el empaquetado y la distribución del software. Además, proporciona un sistema de construcción estandarizado y una estructura de proyecto coherente, lo que hace que sea más fácil para los desarrolladores trabajar en proyectos grandes y complejos. Además, proporciona gestión de dependencias, es decir, permite que un proyecto pueda utilizar librerías de terceros sin tener que preocuparse de cómo se instalan, cómo se actualizan, etc. Pero Maven es mucho más que eso: el objetivo principal de es permitir que un desarrollador comprenda el estado completo de un esfuerzo de desarrollo en el menor tiempo posible. Para lograr este objetivo, Maven se ocupa de varias áreas:

Facilitar el proceso de construcción
Proporcionar un sistema de construcción uniforme
Proporcionar información de proyectos de calidad
Fomentar mejores prácticas de desarrollo

Objetivos

* *

Prerrequisitos

El guion de esta actividad está actualizado para JUnit 5. Para cada proyecto de la actividad 05 - Pruebas Unitarias en JUnit.

Configuración del UTF-8 en el IDE

Eclipse

Eclipse Si estás usando Eclipse, no olvides configurar Eclipse para que utilice UTF-8 como codificación predeterminada: Window > Preferencies > General > Workspace > Text file encoding > Other > UTF-8

Visual Studio Code

VSCode Si usas VS Code para desarrollar en Java:

Instala las extensiones Java, Maven, Java Debugger
Si no configuras el UTF-8 en el IDE, los tests de caracteres con acentos o con eñes fallarán. Configurar UTF-8 en la compilación y depuración con Java: Extensions / Java Debugger

Esto se traduce en el archivo de settings.json del usuario en:

   "java.debug.settings.vmArgs": "-Dfile.encoding=UTF-8"

Pasos a seguir

1. Convertir a proyecto Maven

Eclipse Si en la actividad 5 habías partido del proyecto en GitHub, como ualhmis/junitEjercicios o ualhmis/hmis-coches, este paso y los dos siguientes ya están hechos. Simplemente debes comprobar que ya lo habíamos hecho en la actividad 5. Si, por el contrario, tu(s) proyecto(s) de la actividad 5 no están mavenizados, hazlo ahora:

Sobre el proyecto, botón derecho, Configure, Convert to maven project

Verás que se ha creado un nuevo archivo llamado pom.xml que es el que contiene la configuración de Maven para el proyecto.

VSCode Si usas VS Code para desarrollar en Java, haz lo siguiente:

Crea un archivo pom.xml en la raíz del proyecto, con el siguiente contenido básico:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>hmis-coches</groupId>
	<artifactId>hmis-coches</artifactId>
	<version>0.0.1-SNAPSHOT</version>
    <build>
    	<plugins>
			<plugin>
				<artifactId>maven-compiler-plugin</artifactId>
				<version>3.11.0</version>
				<configuration>
					<release>11</release>
				</configuration>
			</plugin>
        </plugins>
    </build>
</project>

El contenido mínimo del pom.xml es:

project root
modelVersion - debe ser 4.0.0
groupId - identificador del grupo del proyecto.
artifactId - identificador de artefacto (proyecto)
version - version del artefacto bajo el grupo especificado

Los parámetros groupId, artifactId, y version forma el nombre completo de artefacto del proyecto (project’s fully qualified artifact name). Este nombre tiene la forma <groupId>:<artifactId>:<version>. En el ejemplo anterior, sería hmis-coches.hmis-coches:0.0.1-SNAPSHOT.

build - contiene la configuración de construcción del proyecto, y los plugins que se ejecutan durante la misma. En el ejemplo anterior, se configura el plugin maven-compiler-plugin para que compile con Java 11.

2. Configurar el archivo `pom.xml`

La estructura predeterminada de un proyecto Maven sigue una convención denominada "Standard Directory Layout" (Estructura de Directorios Estándar), que proporciona una forma coherente de organizar los archivos de un proyecto. Esta estructura se compone de los siguientes directorios y subdirectorios:

El directorio src/main/java contiene el código fuente principal del proyecto.
El directorio src/main/resources contiene los recursos (archivos de configuración, archivos de propiedades, etc.) necesarios para que el proyecto se ejecute.
El directorio src/test/java contiene los archivos de prueba del proyecto.
El directorio src/test/resources contiene los recursos necesarios para las pruebas.
El archivo pom.xml es el archivo de configuración de Maven que describe cómo se debe construir el proyecto, incluyendo las dependencias, plugins y otros detalles.
El directorio target es donde Maven coloca los resultados de la construcción y el empaquetado del proyecto.

Si tu proyecto Java tiene otra estructura distinta a esta estructura de carpetas predeterminada, puedes modificarla en el archivo pom.xml. Por ejemplo, partiendo de la estructura de proyecto habitual en Eclipse, los fuentes están en la carpeta src y las clases con tests en la carpeta test.

Para empezar, debes configurar el proyecto con codificación UTF-8, y las carpetas donde están los fuentes y los tests:

<properties>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
</properties>

<build>
  <sourceDirectory>src</sourceDirectory>
  <testSourceDirectory>test</testSourceDirectory>
   ...
</build>

3. Añadir las dependencias a JUnit5

Maven proporciona gestión de dependencias, es decir, permite que un proyecto pueda utilizar librerías de terceros sin tener que preocuparse de cómo se instalan, cómo se actualizan, etc. A partir de ahora, deberás configurar el archivo pom.xml para que incluya las dependencias necesarias para el proyecto.

Añade las dependencias a JUnit 5 (simplemente comprobar, ya lo habíamos hecho en la actividad 5):

	<dependency>
		<groupId>org.junit.jupiter</groupId>
		<artifactId>junit-jupiter-engine</artifactId>
		<version>5.9.2</version> (1)
		<scope>test</scope>
	</dependency>
	<dependency>
		<groupId>org.junit.jupiter</groupId>
		<artifactId>junit-jupiter-api</artifactId>
		<version>5.9.2</version>
		<scope>test</scope>
	</dependency>
   	<dependency>
		<groupId>org.junit.jupiter</groupId>
		<artifactId>junit-jupiter-params</artifactId>
		<version>5.9.2</version>
		<scope>test</scope>
	</dependency>

1	La versión de JUnit5 que usamos en el momento de escribir este documento es la `5.9.2`, pero debes comprobar la última versión en https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter-api y usarla en tu `pom.xml`, en las tres dependencias de JUnit5.

Eclipse En Eclipse, hay que eliminar JUnit del ClassPath del proyecto

Si en el proyecto aparecen errores de compilación tras añadir las dependencias a Junit en Maven, se debe actualizar el proyecto: sobre el proyecto, botón derecho, Maven, Update Project.

4. Lanzar los test desde Maven

Maven define un ciclo de vida (Maven lifecycle) para compilar/test/empaquetar el proyecto. El ciclo de vida de Maven es un conjunto predefinido de fases que describen el proceso de construcción y distribución de un proyecto. Cada fase representa una etapa específica en el ciclo de vida de construcción de un proyecto, y se ejecutan en un orden predefinido.

Los goals de Maven son tareas específicas que se pueden ejecutar en un proyecto durante el proceso de construcción. Cada fase del ciclo de vida de Maven está compuesta por uno o más goals, y los goals se utilizan para realizar acciones específicas, como compilar el código fuente, ejecutar pruebas, empaquetar el proyecto, instalar el proyecto en el repositorio local de Maven, y desplegar el proyecto en un servidor remoto.

Por ejemplo, en la fase compile del ciclo de vida de Maven, el goal principal es compile, que se utiliza para compilar el código fuente del proyecto y generar archivos .class. En la fase test, el goal principal es test, que se utiliza para ejecutar las pruebas unitarias del proyecto. En la fase package, el goal principal es package, que se utiliza para empaquetar el proyecto en un archivo .jar o .war. El goal clean se utiliza para limpiar el resultado de la construcción anterior, borrando en la carpeta target.

La carpeta target nunca se guarda en el respositorio Git, ni se sube a GitHub. Git ignora está carpeta porque se encuentra dentro del archivo .gitignore.

En cada goal se ejecutan otros goals previos necesarios para que el actual se ejecute correctamente. Por ejemplo, al ejecutar test, Maven ejecuta previamente compile y testCompile. Del mismo modo, package ejecuta previamente los goals compile, testCompile y test.

Figure 1. Maven lifecycle goals

Eclipse Normalmente hasta ahora siempre hemos ejecutado los tests de JUnit desde Eclipse, con la opción Run As… JUnit test. Ahora vamos a lanzar los test desde Maven: Sobre el proyecto, Botón derecho, Run as… , Maven build. En el campo Goals: clean package

VSCode En VS Code, para lanzar los test desde Maven, desde el terminal ejecuta:

mvn clean package

Recuerda que para ejecutar los test con Maven desde el terminal, debes tener instalado Maven en tu sistema operativo. Comprueba que lo tienes instalado con el comando mvn -v. Si no lo tienes instalado, puedes descargarlo desde https://maven.apache.org/download.cgi, aunque la instalación recomendada en Windows es con Chocolatey: https://chocolatey.org/packages/maven

Si maven no compila, da error: del tipo --release en maven (el pom.xml tiene release 11):

check your JAVA_HOME environment variable.
I was setting the value of release to 11 as I am using JAVA 11.
My System JAVA_HOME was set for java 8.
After changing the JAVA_HOME user environment variable to the java 11 path, this got resolved.

Una vez ejecutada correctamente la construcción con Maven, comprueba en la salida por consola que se hayan ejecutando los tests correctamente: número de tests, Passed, Failed, …

En caso de que no se estén ejecutando los tests (Tests run: 0) el problema es que Maven no está encontrando los tests. Para solucionarlo es necesario configurar el plugin Surefire, encargado de los tests unitarios, tal y como se explica en la siguiente sección.

Puedes comprobar el resultado de la ejecución de los test de JUnit abriendo el archivo xml generado en la carpeta target/surefire-reports/TEST-….xml

Si en la consola aparece el siguiente error:

No compiler is provided in this environment. Perhaps you are running on a JRE rather than a JDK?

En Eclipse: Window → Preferences → Java → Installed JREs. Comprueba que está marcada una instalación de JDK en lugar de un JRE.

Si no tuvieses instalado un JDK, debes instalarlo. Recomendable JDK 11. Tras instalarlo, debes reiniciar Eclipse y añadirlo a la lista de Installed JREs.

5. Surefire plugin

Surefire es el plugin de Maven que se encarga de ejecutar los tests unitarios. Por defecto, Surefire busca los tests en el directorio src/test/java y los ejecuta. Si no se encuentra ningún test, no se ejecuta ninguno. Por eso, si no se ejecutan los tests, es porque Maven no los encuentra.

Añade esta configuración del plugin al pom.xml

<build>
   <plugins>
	...
	<plugin>
		<groupId>org.apache.maven.plugins</groupId>
		<artifactId>maven-surefire-plugin</artifactId>
		<version>3.0.0</version>
	</plugin>
	...
   </plugins>
</build>

De forma predeterminada, Surefire incluye automáticamente todos los archivos de pruebas que cumplen las siguientes reglas de nomenclatura:

**/Test*.java, incluye todos los archivos .java que empiezan por Test.
**/*Test.java, archivos .java que finalizan en Test.
**/*Tests.java, archivos .java que finalizan en Tests.
**/*TestCase.java, archivos .java que finalizan en TestCase.

Si tus clases de test no siguen esta nomenclatura, debes configurar el plugin para especificar qué archivos debe incluir:

...
	<plugin>
		<groupId>org.apache.maven.plugins</groupId>
		<artifactId>maven-surefire-plugin</artifactId>
		<version>3.0.0</version>
		<configuration>
            <includes>
                <include>Sample.java</include>
            </includes>
		</configuration>
	</plugin>
...

Y si deseas excluir algún archivo de test, debes añadirlo a la lista de exclusiones:

...
	<plugin>
		<groupId>org.apache.maven.plugins</groupId>
		<artifactId>maven-surefire-plugin</artifactId>
		<version>3.0.0</version>
		<configuration>
            <excludes>
              <exclude>**/TestCircle.java</exclude>
              <exclude>**/TestSquare.java</exclude>
            </excludes>
          </configuration>
	</plugin>
...

Más info en Inclusion/Exclusion of Tests

La siguiente extensión muestra en la consola una vista en forma de árbol de las pruebas unitarias . Esto está relacionado con las pruebas JUnit5:

...
	<plugin>
		<groupId>org.apache.maven.plugins</groupId>
		<artifactId>maven-surefire-plugin</artifactId>
		<version>3.0.0</version>
		<dependencies>
			<dependency>
				<groupId>me.fabriciorby</groupId>
				<artifactId>maven-surefire-junit5-tree-reporter</artifactId>
				<version>0.1.0</version>
			</dependency>
		</dependencies>
		<configuration>
			<reportFormat>plain</reportFormat>
			<consoleOutputReporter>
				<disable>true</disable>
			</consoleOutputReporter>
			<statelessTestsetInfoReporter implementation="org.apache.maven.plugin.surefire.extensions.junit5.JUnit5StatelessTestsetInfoTreeReporter" />
			<argLine>@{argLine} -Dfile.encoding=UTF-8</argLine>
			<!-- -Dfile.encoding=UTF-8 necesario para que pasen los tests con UTF-8 -->
			<!-- @{argLine} necesario para Jacoco !!! -->
		</configuration>
	</plugin>

...

6. Plugin de Cobertura

Para el cálculo de la cobertura desde Maven vamos a usar el plugin JaCoCo.

<project...>
...
<build>
    <plugins>
		<plugin>
			<groupId>org.jacoco</groupId>
			<artifactId>jacoco-maven-plugin</artifactId>
			<version>0.8.8</version>
			<executions>
				<execution>
					<id>prepare-agent</id>
					<goals>
						<goal>prepare-agent</goal>
					</goals>
				</execution>
				<!-- attached to Maven test phase -->
				<execution>
					<id>report</id>
					<phase>test</phase>
					<goals>
						<goal>report</goal>
					</goals>
				</execution>
			</executions>
		</plugin>
	</plugins>
</build>
...
</project>

Para llamar al cálculo de cobertura desde la línea de comandos, ejecuta el siguiente comando:

mvn clean package

Para ver el informe de cobertura, abre el archivo target/site/jacoco/index.html con el navegador web.

Puedes navegar y ver la cobertura linea a linea. Recuerda los colores:

Puedes verificar que los resultados de la cobertura desde Maven con JaCoCo son iguales que los resultados de la cobertura obtenidos por el plugin EclEmma de Eclipse.

7. Verificar un valor mínimo de cobertura

Además, se puede añadir una regla de verificación para que la construcción solamente de éxito si la cobertura es superior a un porcentaje mínimo.

...
			<!-- Add this checking: coverage >= 90% -->
			<execution>
				<id>jacoco-check</id>
				<goals>
					<goal>check</goal>
				</goals>
				<configuration>
					<rules>
						<rule>
							<element>PACKAGE</element>
							<limits>
								<limit>
									<counter>LINE</counter>
									<value>COVEREDRATIO</value>
									<minimum>0.9</minimum>
								</limit>
							</limits>
						</rule>
					</rules>
				</configuration>
			</execution>
...

Si además quieres que se comprueben las reglas de verificación, ejecuta el siguiente los goals clean y verify:

mvn clean verify

Si no se alcanza el mínimo, en este caso 90%, por consola se muestra el siguiente error:

Más info en https://dzone.com/articles/reporting-code-coverage-using-maven-and-jacoco-plu

8. Análisis estático de Código

Para mantener o aumentar la calidad de nuestro código debemos ayudarnos, entre otras herramientas, de técnicas de análisis estático de código que, básicamente, se encargan de buscar defectos en el código sin necesidad de que este se ejecute. En Java las más habituales son Checkstyle, FindBugs y PMD.

Checkstyle valida el estilo del código respecto al estilo oficial de Java.
FindBugs/Spotbugs busca errores comunes.
PMD valida reglas de construcción y compilación.

8.1. Site

El plugin Maven Site genera un sitio web con documentación del proyecto. Se invoca con el goal: site. Hay que añadirlo en el bloque build y en el bloque reporting del pom.xml.

<project>
  ...
  <build>
  ...
	<plugin>
		<groupId>org.apache.maven.plugins</groupId>
		<artifactId>maven-site-plugin</artifactId>
		<version>4.0.0-M7</version>
		<configuration>
			<locales>es,en</locales>
		</configuration>
	</plugin>
	  ...
  </build>
   <reporting>
    <plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-site-plugin</artifactId>
			<version>4.0.0-M7</version>
			<configuration>
				<locales>es,en</locales>
			</configuration>
		</plugin>
        ...
	</plugins>
  </reporting>
  ...
</project>

8.2. Checkstyle

Para configurar estas 3 herramientas en Maven, dentro del pom.xml se añaden en el bloque reporting que se encarga de generar los informes de las herramientas de análisis estático de código. Utiliza el plugin site de Maven.

<project>
  ...
  </build>
  <reporting>
    <plugins>
		...
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-checkstyle-plugin</artifactId>
            <version>3.1.1</version>
        </plugin>

		<plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jxr-plugin</artifactId>
            <version>3.3.0</version>
        </plugin>
    </plugins>
  </reporting>
  ...
</project>

Checkstyle se invoca simplemente con el goal: checkstyle:checkstyle

Sin embargo, puesto que vamos a generar varios informes de análisis estático de código, y con el objetivo de que todos se generen correctamente, hay que llamar a los 3 plugins desde un único goal: site.

En target/site/ se genera el archivo index.html que será el punto de inicio, y otro checkstyle.html.

Filtro de reglas: Checkstyle permite seleccionar una lista reglas, de archivos y rango de lineas que no se incorporarán al informe (conocido como suppressions filter).

8.3. PMD

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-pmd-plugin</artifactId>
	<version>3.20.0</version>
	<configuration>
		<linkXref>true</linkXref>
		<sourceEncoding>utf-8</sourceEncoding>
		<minimumTokens>100</minimumTokens>
		<targetJdk>1.8</targetJdk>
		<skipEmptyReport>false</skipEmptyReport>
		<rulesets>
			<ruleset>/rulesets/java/braces.xml</ruleset>
			<ruleset>/rulesets/java/naming.xml</ruleset>
		</rulesets>
	</configuration>
</plugin>

8.4. FindBugs/Spotbugs

Spotbugs es la nueva versión de FindBugs.

...

	<plugin>
		<groupId>com.github.spotbugs</groupId>
		<artifactId>spotbugs-maven-plugin</artifactId>
		<version>4.7.3.4</version>
		<configuration>
			<effort>Max</effort>
			<threshold>Low</threshold>
			<failOnError>true</failOnError>
			<includeFilterFile>${session.executionRootDirectory}/spotbugs-security-include.xml</includeFilterFile>
			<excludeFilterFile>${session.executionRootDirectory}/spotbugs-security-exclude.xml</excludeFilterFile>
			<plugins>
				<plugin>
					<groupId>com.h3xstream.findsecbugs</groupId>
					<artifactId>findsecbugs-plugin</artifactId>
					<version>1.12.0</version>
				</plugin>
			</plugins>
		</configuration>
	</plugin>
...

Se puede integrar la búsqueda de Security Bugs en SpotBugs. Find Security Bugs es un plugin de SpotBugs para seguridad que audita aplicaciones Java web y Android.

Además, junto al archivo pom.xml debes crear estos dos archivos:

spotbugs-security-include.xml

<FindBugsFilter>
    <Match>
        <Bug category="SECURITY,MALICIOUS_CODE,CORRECTNESS,BAD_PRACTICE "/>
    </Match>
</FindBugsFilter>

spotbugs-security-exclude.xml

<FindBugsFilter>
</FindBugsFilter>

El resultado se genera en .xml además de en el informe html. Su contenido se visualizará en Jenkins.

Referencia: https://www.javaworld.com/article/3123117/open-source-java-projects-jenkins-with-docker-part-1.html

9. Documentación JavaDoc

El Plugin Javadoc utiliza la herramienta JavaDoc para generar la documentación de las clases del proyecto en formato html. Para ello, hay que ejecutar el goal javadoc:javadoc

El resultado se genera en la carpeta target/site/apidocs

El plugin de javadoc debe aparecer repetido tanto en el bloque bulid como en el bloque reporting del pom.xml. De esta manera, cuando llamemos a site se generará el informe de análisis estático de código y la documentación JavaDoc integrada en el informe. Y cuando llamemos simplemente a javadoc:javadoc se generará únicamente la documentación JavaDoc.

	<plugin>
		<groupId>org.apache.maven.plugins</groupId>
		<artifactId>maven-javadoc-plugin</artifactId>
		<version>3.5.0</version>
		<configuration>
			<show>private</show>
		</configuration>
	</plugin>

9.1. Diagramas de clases

Al igual que la documentación JavaDoc, con Maven se pueden crear automáticamente diagramas de clases UML a partir del código.

Actualiza la configuración del plugin JavaDoc en el archivo pom.xml para que genere también los diagramas de clases. Y añade la dependencia al plugin necesario umldoclet.

...
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
        <version>3.5.0</version>
        <configuration> (1)
          <!-- <reportOutputDirectory>
		  	${project.reporting.outputDirectory}/../../docs
		  </reportOutputDirectory> -->
          <doclet>nl.talsmasoftware.umldoclet.UMLDoclet</doclet>
          <docletArtifact>
            <groupId>nl.talsmasoftware</groupId>
            <artifactId>umldoclet</artifactId>
            <version>2.1.0</version>
          </docletArtifact>
          <additionalOptions>
            <!-- -umlImageFormat (svg | svg_img | png | eps | none) -->
			<!-- <additionalOption>-umlImageFormat svg_img,png</additionalOption> -->
			<additionalOption>-umlImageFormat svg_img</additionalOption>
			<additionalOption>-private</additionalOption>
			<!-- <additionalOption>-createPumlFiles</additionalOption> -->
			<additionalOption>-umlExcludedTypeReferences</additionalOption> <!-- añade metodos toString() y equals() -->
			<!-- <additionalOption>-umlJavaBeanPropertiesAsFields</additionalOption> -->
			<!-- <additionalOption>-umlCustomDirective "skinparam classBackgroundColor
					LightYellow"</additionalOption> -->
          </additionalOptions>
        </configuration>
      </plugin>
    </plugins>
  </build>
  <dependencies> (2)
    <!-- https://mvnrepository.com/artifact/nl.talsmasoftware/umldoclet -->
    <dependency>
      <groupId>nl.talsmasoftware</groupId>
      <artifactId>umldoclet</artifactId>
      <version>2.1.0</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>
</project>

1	Bloque de configuración del plugin javadoc para que genere los diagrama UML
2	Bloque de dependencias necesarias para la generación de los diagrama UML

Guarda los cambios y vuelve a ejecutar maven. Ahora los JavaDoc se crean en la carpeta docs/apidocs que deberás proteger en el repositorio. Verás que tus JavaDoc incluyen los diagramas de clases.

Figure 2. Ejemplo de diagramas de clases generados

Recuerda que si en Eclipse en el proyecto aparecen errores (archivos en rojo) tras la modificación del pom.xml, se debe actualizar el proyecto Maven: sobre el proyecto, botón derecho, Maven > Update Project.

10. OWASP Dependency Check

Uno de los fallos de seguridad más comunes en las aplicaciones web es el uso de componentes con vulnerabilidades de ciberseguridad conocidas. Esto ocurre cuando no comprobamos el historial de seguridad de las librerías que incorporamos a nuestros proyectos. Con frecuencia, basta con actualizar a las últimas versiones.

Dependency Check de OWASP es una herramienta que permite identificar las dependencias de nuestro proyecto y comprobar si hay alguna de ellas que tiene vulnerabilidades conocidas. Cuando una dependencia tiene identificada una vulnerabilidad, se listarán las entradas asociadas al Common Vulnerability and Exposure (CVE). Las vulnerabilidades y exposiciones comunes (CVE), es una lista de información registrada sobre vulnerabilidades de seguridad conocidas.

La primera ejecución es más lenta, puede tardar más de 5 minutos, porque necesitará descargar todas las referencias de las evidencias de la base de datos National Vulnerability Database (NVD) (https://nvd.nist.gov).

El siguiente ejemplo configura el plugin en el bloque reporting para añadir al informe del proyecto un informe de comprobación de dependencias (agregado al site). Se invocará como parte del goal site

	<plugin>
		<groupId>org.owasp</groupId>
		<artifactId>dependency-check-maven</artifactId>
		<version>8.2.1</version>
		<configuration>
			<skipTestScope>false</skipTestScope>
			<formats>
				<format>HTML</format>
				<format>XML</format>
			</formats>
		</configuration>
		<reportSets>
			<reportSet>
				<reports>
					<report>aggregate</report>
				</reports>
			</reportSet>
		</reportSets>
	</plugin>

Añadiendo dependencias con vulnerabilidades: Para probar como el plugin detecta dependencias con vulnerabilidades conocidas, añade al pom.xml las siguientes dependencias:

	<!-- Examples of vulnerable dependencies -->
	<dependency>
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
		<version>4.12</version>
		<scope>test</scope>
	</dependency>

	<dependency>
		<groupId>org.apache.commons</groupId>
		<artifactId>commons-collections4</artifactId>
		<version>4.0</version>
	</dependency>

	<dependency>
		<groupId>org.apache.commons</groupId>
		<artifactId>commons-collections3</artifactId>
		<version>3.2.2</version>
	</dependency>

	<!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
	<dependency>
		<groupId>org.apache.logging.log4j</groupId>
		<artifactId>log4j-core</artifactId>
		<version>2.15.0</version>
	</dependency>

Tras ello, vuelve a lanzar el análisis y consulta el informe generado:

Entrega

En la tarea correspondiente a la sesion07 debe entregarse un pequeño informe con: las URLs de los repositorios utilizados, que deben coincidir con los de la sesión 05 (recuerda dar acceso al profesor si un repositorio es privado), y una captura de los resultados de los informes generados con Maven en Eclipse o en el terminal de VSCode.

¡RECUERDA! Debes obtener una cobertura del 100% y resolver los defectos encontrados más importantes (no todos) por las herramientas de análisis estático de código.

Maven