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


118

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?

Respuestas:


213

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!


¿Alguien me puede decir cuál es la diferencia entre fase y meta en ejecución? Como sabía, la fase está hablando del ciclo de vida de maven ... pero ¿por qué volver a meta? alguna pista? A veces veo que la gente pone la palabra clave del ciclo de vida en la meta ... ??? (?.?)
taymedee

@taymedee esta pregunta SO describe la diferencia: stackoverflow.com/questions/16205778/…
dev_feed

1
@ r981 Tu respuesta debe ser más clara. Esta respuesta es mejor: stackoverflow.com/questions/26292073/…
Impermanencia digital

Creo que el punto perdido de esta respuesta es que: las dependencias de nivel superior son utilizadas principalmente por su artefacto en lugar de los complementos.
gratis el

3
@MichaelPacheco, Lo que quise decir es que spring-plugin realizará una determinada tarea de ejecutar un conjunto de código, que podría depender de algunas bibliotecas, que serán especificadas por las 'dependencias'. Tome un ejemplo diferente: necesita un compilador para ejecutar un fragmento de código; Aquí, su compilador es un complemento y su código es el ejecutable. Su compilador por sí solo es capaz de ejecutar cualquier código, pero su código puede depender de una biblioteca, digamos apache commons, que será una dependencia. Su compilador solo puede compilar el código cuando las dependencias están presentes en el classpath. Espero que ahora esté claro.
r9891

37

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.


gracias por la respuesta rápida, lo siento, pero todavía estoy confundido porque sé que JUnit también es un marco y (hibernate, spring) también viene solo en el marco, por lo que los medios en los casos (hibernate, spring) también se pueden configurar en etiquetas de dependencia ? espero que tengas mi pregunta.
Coral

Sí, y hasta donde yo sé, no existe el plugin Spring Maven. Por lo general, las bibliotecas de Spring (o Hibernate, o JUnit, o TestNG, etc.) se declaran como dependencias para su proyecto. Si eres nuevo en Maven, te recomiendo leer este muy buen libro.
Andrew Logvinov

@AndrewLogvinov - Tengo un proyecto multi pom para pruebas de automatización de API. Uno de los proyectos de maven tiene pruebas de automatización. La sección de compilación del proyecto pom tenía solo 1 complemento: el complemento seguro de maven con referencia a una suite. Se eliminó toda la etiqueta de compilación. ¿Podría decirme qué significa esto? Gracias.
MasterJoe

15

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>

¡gran explicación !, ya que no estoy bien versado en la configuración de dependencias en Java, todavía tengo una duda, actualmente estoy trabajando en IntelliJ y creé un proyecto maven, cuando intenté incluir webdriver-ietengo dos opciones, o incluirlo como pluginso dependency, incluí ambos para comparar, y observé que ambos tienen exactamente lo mismo, groupIdla única diferencia es que pluginsno vienen con una versión específica, pero dependencyvienen 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?
Anu

1
Es difícil dar la respuesta más exacta sin ver tu 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)
davidxxx

1
Tenga en cuenta que es una mala forma de especificar un complemento. No hace que su construcción sea reproducible con el tiempo ( cwiki.apache.org/confluence/display/MAVEN/… ). Debería ver una advertencia en la compilación. Entonces cuál es la diferencia ?". Los complementos realizan tareas para una compilación de Maven, mientras que la dependencia son bibliotecas (jar o lo que sea) necesarias en la ruta de clases durante la compilación. Si la compilación de su proyecto es la misma en cualquier caso (usando la biblioteca o el complemento), significa que el complemento está indefenso porque no se usa. (2/2)
davidxxx

6

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.


4

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.


1

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) 

1

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


0

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.

complemento y dependencia

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.