Los complementos y las dependencias son cosas muy diferentes y complementarias.
¿Qué complementos son?
Los complementos realizan tareas para una compilación de Maven. Estos no están empaquetados en la aplicación.
Estos son el corazón de Maven.
Cualquier tarea ejecutada por Maven se realiza mediante complementos .
Hay dos categorías de plugins: el buildy los reportingcomplementos :
- Los complementos de compilación se ejecutarán durante la compilación y deben configurarse en el
<build/>elemento del POM.
- Los complementos de informes se ejecutarán durante la generación del sitio y deben configurarse en el
<reporting/elemento> del POM.
De acuerdo con el objetivo de maven especificado en la línea de comando (por ejemplo mvn clean, mvn clean packageo mvn site), se utilizará un ciclo de vida específico y se ejecutará un conjunto específico de objetivos de complementos.
Hay tres armarios ciclos de vida: construcción default, cleany site. El defaultciclo de vida maneja la implementación de su proyecto, el cleanciclo de vida maneja la limpieza del proyecto, mientras que el siteciclo de vida maneja la creación de la documentación del sitio de su proyecto.
El objetivo de un complemento puede estar vinculado a una fase específica de un ciclo de vida específico.
Por ejemplo, los maven-compiler-pluginune de manera predeterminada la compilemeta a la fase del ciclo de vida: compile.
La mayoría de los complementos de Maven (tanto los complementos principales como los de terceros) prefieren la convención sobre la configuración. Por lo tanto, estos generalmente vinculan el objetivo de un complemento a una fase específica para simplificar su uso.
Eso es más ordenado y menos propenso a errores:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
</plugin>
que:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
¿Qué dependencias son?
Las dependencias son artefactos / componentes de Maven necesarios en la ruta de clases durante la compilación de Maven.
Estos pueden estar empaquetados en la aplicación, pero no necesariamente (ver más scopeabajo).
La mayoría de las dependencias son jar, pero también pueden ser otros tipos de archivos: war, ear, test-jar, ejb-client ... o aún POM o BOM.
En un pom.xml, las dependencias se pueden especificar en varios lugares: la <build><dependencies>parte, la dependencies managementparte o aún en una plugindeclaración . De hecho, es posible que algunos complementos necesiten tener algunas dependencias en la ruta de clases durante su ejecución. Eso no es común pero puede suceder.
Aquí hay un ejemplo de la documentación que muestra que pluginy dependencypueden funcionar juntos:
Por ejemplo, la versión 1.2 del complemento Maven Antrun usa la versión 1.6.5 de Ant, si desea utilizar la última versión de Ant al ejecutar este complemento, debe agregar un <dependencies>elemento como el siguiente:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.2</version>
...
<dependencies>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.7.1</version>
</dependency>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant-launcher</artifactId>
<version>1.7.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
...
</project>
En Maven, se hace referencia a las dependencias en un formato específico:
groupId:artifactId:packaging:classifier:version.
El clasificador (que es opcional) y el empaque ( JARpor defecto) no se especifican comúnmente. Por lo que el formato común en la dependencydeclaración es más bien: groupId:artifactId:version.
Aquí hay un ejemplo de dependencia declarada en la <build><dependencies>parte:
<build>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>5.2.14.Final</version>
</dependency>
<dependencies>
</build>
A diferencia de un complemento, una dependencia tiene un alcance.
El alcance predeterminado es compile. Ese es el alcance más comúnmente necesario (convención sobre configuración nuevamente).
loscompile alcance significa que la dependencia está disponible en todas las rutas de clase de un proyecto.
El alcance define en qué rutas de clases se debe agregar la dependencia. Por ejemplo, ¿lo necesitamos en tiempo de compilación y ejecución, o solo para compilación y ejecución de pruebas?
Por ejemplo, previamente definimos Hibernate como una compiledependencia, ya que lo necesitamos en todas partes: compilación de código fuente, compilación de prueba, tiempo de ejecución, etc.
Pero no queremos que las bibliotecas de prueba puedan estar empaquetadas en la aplicación o referenciadas en el código fuente. . Entonces especificamos el testalcance para ellos:
<build>
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.1.0</version>
<scope>test</scope>
</dependency>
<dependencies>
</build>
