Respuestas:
Tanto los complementos como las dependencias son archivos Jar.
Pero la diferencia entre ellos es que la mayor parte del trabajo en maven se realiza mediante complementos; mientras que la dependencia es solo un archivo Jar que se agregará a la ruta de clases mientras se ejecutan las tareas.
Por ejemplo, usa un complemento de compilación para compilar los archivos java. No puede usar compilador-complemento como dependencia, ya que eso solo agregará el complemento a la ruta de clases y no activará ninguna compilación. Los archivos Jar que se agregarán a la ruta de clases mientras se compila el archivo se especificarán como una dependencia.
Lo mismo ocurre con tu escenario. Tienes que usar spring-plugin para ejecutar algunos ejecutables de Spring [no estoy seguro de para qué se usan los Spring-Plugins. Solo estoy adivinando aquí]. Pero necesitas dependencias para ejecutar esos ejecutables. Y Junit está etiquetado como dependencia, ya que surefire-plugin lo usa para ejecutar pruebas unitarias.
Entonces, podemos decir que el complemento es un archivo Jar que ejecuta la tarea, y la dependencia es un Jar que proporciona los archivos de clase para ejecutar la tarea.
¡Espero que responda a tu pregunta!
El propio Maven puede describirse como un procesador de alimentos que tiene muchas unidades diferentes que se pueden usar para realizar diferentes tareas. Esas unidades se denominan complementos. Por ejemplo, para compilar su proyecto, maven usa maven-compiler-plugin
, para ejecutar pruebas, maven-surefire-plugin
etc.
La dependencia en términos de maven es una pieza empaquetada de clases de las que depende su proyecto. Puede ser jar, war, etc. Por ejemplo, si desea poder escribir la prueba JUnit, tendrá que usar anotaciones y clases JUnit, por lo que debe declarar que su proyecto depende de JUnit.
Los complementos y las dependencias son cosas muy diferentes y complementarias.
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 build
y los reporting
complementos :
<build/>
elemento del POM.<reporting/
elemento> del POM. De acuerdo con el objetivo de maven especificado en la línea de comando (por ejemplo mvn clean
, mvn clean package
o 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
, clean
y site
. El default
ciclo de vida maneja la implementación de su proyecto, el clean
ciclo de vida maneja la limpieza del proyecto, mientras que el site
ciclo 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-plugin
une de manera predeterminada la compile
meta 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>
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 scope
abajo).
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 management
parte o aún en una plugin
declaració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 plugin
y dependency
pueden 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 ( JAR
por defecto) no se especifican comúnmente. Por lo que el formato común en la dependency
declaració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 compile
dependencia, 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 test
alcance 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>
webdriver-ie
tengo dos opciones, o incluirlo como plugins
o dependency
, incluí ambos para comparar, y observé que ambos tienen exactamente lo mismo, groupId
la única diferencia es que plugins
no vienen con una versión específica, pero dependency
vienen con 0.6.685
. ¿Podría explicarlo en términos simples (en relación con este ejemplo) cuál es la diferencia, cuál usar y cuándo? ¿Cualquier sugerencia?
pom.xml
. Pero algo que debería interesarle es que especificar la versión de dependencia es obligatorio (en el pom actual o en el pom principal si es una dependencia heredada) en cualquier versión de Maven mientras que desde Maven 3 (probablemente una mala buena idea como característica), especificar la versión del complemento es opcional. Maven usará la última versión disponible en el repositorio de versiones donde la encuentre. (1/2)
Si viene de un entorno front-end como yo, y está familiarizado con Grunt y npm, piénselo así:
En primer lugar debe ejecutar, por ejemplo, npm install grunt-contrib-copy --save-dev
. Esto es como maven<dependency></dependency>
. Descarga los archivos necesarios para ejecutar una tarea de compilación.
Luego configuraría la tarea en Gruntfile.js
copy: {
main: {
src: 'src/*',
dest: 'dest/',
},
}
Esto es como el de Maven <plugin>/<plugin>
. Le está diciendo a la herramienta de compilación qué hacer con el código descargado por npm / <dependency></dependency>
.
Por supuesto, esta no es una analogía exacta, pero lo suficientemente cercana como para ayudarlo a entenderlo.
Los complementos se utilizan para agregar funcionalidades a Maven
sí mismo (como agregar eclipse
soporte o SpringBoot
soporte a, Maven
etc.). El código fuente necesita las dependencias para pasar cualquier fase de Maven ( compile
o test
por ejemplo). En el caso de JUnit
que el código de prueba es básicamente parte de su base de código y usted llama a JUnit
comandos específicos dentro de las suites de prueba y esos comandos no se proporcionan, por lo Java SDK
tanto, JUnit
deben estar presentes en el momento Maven
en que se encuentra en la fase de prueba y esto se maneja mencionando JUnit
como una dependencia. en su pom.xml
archivo.
En esencia, Maven es un marco de ejecución de complementos, según la definición compacta formal y estándar. Para que quede más claro, los comandos que usa como maven-install/clean/compile/build etc
para crear / ejecutar archivos jar, que a veces también ejecutamos manualmente. Entonces, las cosas que desea ejecutar (o configurar o ejecutar) básicamente las coloca en la etiqueta de dependencia de mavens pom y la respuesta para saber quién ejecutará estas dependencias (necesarias para la configuración del entorno) serán los complementos.
javac (compiler) dependency.java (dependency)
Respuesta de una línea: comprensión básica
El complemento es una herramienta que usa en la ejecución de su compilación maven
Dependencia significa cualquier tipo de biblioteca que usará en su código
Un complemento es una extensión de Maven, algo que se usa para producir su artefacto (maven-jar-plugin, por ejemplo, se usa para, lo adivina, hacer un jar con sus clases y recursos compilados).
Una dependencia es una biblioteca que necesita la aplicación que está construyendo, durante la compilación y / o prueba y / o tiempo de ejecución.