¿Cuál es la diferencia en maven entre las etiquetas de dependencia y de complemento en pom xml?

Soy nuevo en la herramienta maven, hice un proyecto con Spring e Hibernate y están configurados en pom.xml como complementos, pero JUnit está etiquetado como dependencia. Mi pregunta es ¿cuál es la lógica detrás de uno como complemento y otro como dependencia?

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-pluginetc.

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.

¿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>

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 Mavensí mismo (como agregar eclipsesoporte o SpringBootsoporte a, Mavenetc.). El código fuente necesita las dependencias para pasar cualquier fase de Maven ( compileo testpor ejemplo). En el caso de JUnitque el código de prueba es básicamente parte de su base de código y usted llama a JUnitcomandos específicos dentro de las suites de prueba y esos comandos no se proporcionan, por lo Java SDKtanto, JUnitdeben estar presentes en el momento Mavenen que se encuentra en la fase de prueba y esto se maneja mencionando JUnitcomo una dependencia. en su pom.xmlarchivo.

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 etcpara 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.