it-swarm-es.com

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

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

87
Coral

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 clase mientras se ejecutan las tareas.

Por ejemplo, utiliza un compilador-plugin para compilar los archivos de Java. No puede usar el compilador-complemento como una dependencia ya que solo agregará el complemento a la ruta de clase, y no activará ninguna compilación. Los archivos Jar que se agregarán a la ruta de clase mientras se compila el archivo, se especificarán como una dependencia.

Lo mismo va con tu escenario. Debe usar el complemento de resorte para ejecutar algunos ejecutables de resorte [No estoy seguro de para qué se utilizan los complementos de resorte. Sólo estoy adivinando aquí]. Pero necesitas dependencias para ejecutar esos ejecutables. Y Junit está etiquetado bajo dependencia ya que es utilizado por surefire-plugin para ejecutar pruebas unitarias.

Por lo tanto, 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 su pregunta!

169
r9891

El propio Maven se puede describir como un procesador de alimentos que tiene muchas unidades diferentes que se pueden usar para realizar diferentes tareas. Esas unidades se llaman complementos. Por ejemplo, para compilar su proyecto maven usa maven-compiler-plugin, para ejecutar pruebas - maven-surefire-plugin y así sucesivamente.

La dependencia en términos de maven es un paquete 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 las anotaciones y clases JUnit, por lo que debe declarar que su proyecto depende de JUnit.

31
Andrew Logvinov

Los complementos y las dependencias son cosas muy diferentes y estas son complementarias.

¿Qué son los complementos?

Los complementos realizan tareas para una construcción 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 complementos: los build y los reporting complementos :

  • Los complementos de compilación se ejecutarán durante la compilación y deberían configurarse en el elemento <build/> del POM.
  • Los complementos de informes se ejecutarán durante la generación del sitio y deben configurarse en el elemento <reporting/> 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 ciclos de vida de compilación incorporados: default, clean y site. El ciclo de vida default se encarga de la implementación del proyecto, el ciclo de vida clean se ocupa de la limpieza del proyecto, mientras que el ciclo de vida site se encarga de la creación de la documentación del sitio del proyecto.

Un objetivo de complemento puede estar vinculado a una fase específica de un ciclo de vida específico.
Por ejemplo, maven-compiler-plugin vincula por defecto el objetivo compile a la fase del ciclo de vida: compile.
La mayoría de los complementos de Maven (tanto los complementos principales como los complementos de terceros) prefieren la convención sobre la configuración. Entonces, estos generalmente unen un objetivo de plugin 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 requeridos en el classpath durante la construcción de Maven.
Estos pueden estar empaquetados en la aplicación pero no necesariamente (consulte la scope a continuación).

La mayoría de las dependencias son jar, pero estos 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 pueden especificarse en varios lugares: la parte <build><dependencies>, la parte dependencies management o aún en una declaración de plugin! De hecho, es posible que algunos complementos deban tener algunas dependencias en la ruta de clase 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 trabajar juntos:

Por ejemplo, la versión 1.2 del complemento de Antrun de Maven usa la versión 1.6.5 de Ant. Si desea utilizar la versión de Ant más reciente al ejecutar este complemento, debe agregar el elemento <dependencies> 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, las dependencias están referenciadas 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. Así que el formato común en la declaración dependency es más bien: groupId:artifactId:version.
Aquí hay un ejemplo de dependencia declarada en la parte <build><dependencies>:

<build>
   <dependencies>
      <dependency>
         <groupId>org.hibernate</groupId>
         <artifactId>hibernate-core</artifactId>
         <version>5.2.14.Final</version>
      </dependency>
   <dependencies>
</build>

Al contrario de un complemento, una dependencia tiene un alcance.
El alcance predeterminado es compile. Ese es el alcance más comúnmente necesitado (convención sobre configuración nuevamente).
El alcance compile significa que la dependencia está disponible en todos los classpaths de un proyecto.

El ámbito define en qué classpaths se debe agregar la dependencia. Por ejemplo, ¿lo necesitamos en compilación y tiempo de ejecución, o solo para compilación y ejecución de pruebas?

Por ejemplo, anteriormente definimos Hibernate como una dependencia compile, ya que la necesitamos en todas partes: compilación de origen, compilación de prueba, tiempo de ejecución, etc.
Pero no queremos que las bibliotecas de prueba se empaqueten en la aplicación o se haga referencia en el código fuente. Así que especificamos el alcance test 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>
7
davidxxx

Los complementos se utilizan para agregar funcionalidades a Maven (como agregar Eclipse support o SpringBoot support a Maven etc.). El código fuente necesita las dependencias para pasar cualquier fase de Maven (por ejemplo, compile o test). En el caso de JUnit, ya que el código de prueba es básicamente parte de su base de código y usted llama JUnit comandos específicos dentro de las suites de prueba y Java SDK no proporciona dichos comandos, por lo tanto JUnit debe estar presente en el momento en que Maven está en la fase de prueba y esto se maneja al mencionar JUnit como una dependencia en su archivo pom.xml.

4
coffeMug

Si viene de un fondo de usuario como yo y está familiarizado con Grunt y npm, piense de esta manera:

Primero ejecutaría, digamos, npm install grunt-contrib-copy --save-dev. Esto es como el <dependency></dependency> de maven. 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 <plugin>/<plugin> de maven. Le está diciendo a la herramienta de compilación qué hacer con el código descargado por npm/<dependency></dependency>.

Por supuesto, esto no es una analogía exacta, pero lo suficientemente cerca como para ayudar a envolver su cabeza alrededor de ella.

4
Kevin

Maven en su corazón es un marco de ejecución de plugin, según la definición compacta formal y estándar. Para hacerlo 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) las coloca básicamente 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) 
1
Himanshu Ahuja