¿Cuál es el propósito de la propiedad del clasificador de declaraciones de dependencia de Mavens?


81

Tengo un archivo pom.xml y en eso veo que hay 3 dependencias referenciadas para las mismas, <artifactId>la diferencia está en las etiquetas

<classifier>sources</classifier>
<classifier>javadoc</classifier>

Eliminé las dependencias que tenían SOURCES/JAVADOCy solo mantuve una dependencia. Probé mi aplicación y todo funciona bien.

¿Cuál es el propósito de usar esta etiqueta clasificadora? y por qué necesito duplicar dependencias dos veces para agregar <classifier>etiquetas SOURCES/JAVADOC.

<dependency>
   <groupId>oauth.signpost</groupId>
   <artifactId>signpost-commonshttp4</artifactId>
   <version>1.2.1.2</version>
   <type>jar</type>
   <scope>compile</scope>
</dependency>
  <dependency>
   <groupId>oauth.signpost</groupId>
   <artifactId>signpost-commonshttp4</artifactId>
   <version>1.2.1.2</version>
   <type>jar</type>
      ***<classifier>javadoc</classifier>***
   <scope>compile</scope>
</dependency>
<dependency>
   <groupId>oauth.signpost</groupId>
   <artifactId>signpost-commonshttp4</artifactId>
   <version>1.2.1.2</version>
   <type>jar</type>
   ***<classifier>sources</classifier>***
   <scope>compile</scope>
</dependency> 

Respuestas:


65

El clasificador distingue los artefactos que se crearon a partir del mismo POM pero que difieren en contenido. Es una cadena opcional y arbitraria que, si está presente, se agrega al nombre del artefacto justo después del número de versión.

Fuente


1
Según el documento dice 'que las fuentes de los clasificadores y javadoc se utilizan para implementar el código fuente del proyecto y los documentos API junto con los archivos de clase empaquetados', ¿qué significa eso? Creo que esa es la razón por la que mi pom.xml lo usa. ¿Por qué necesita implementar los documentos de la API y el código fuente junto con las clases empaquetadas? ¿No es lo suficientemente bueno implementar clases empaquetadas?
pushya

6
@pushya normalmente cuando implementa sus artefactos en un repositorio público como Maven central, incluye los javadocs y las fuentes para que los IDE con soporte de Maven puedan completar correctamente el código y las ventanas emergentes JavaDoc, y puedan ingresar al código de la biblioteca al depurar.
Ian Roberts

@IanRoberts eso tiene sentido ahora. ¿De modo que eso significa que puedo eliminar las dependencias que tienen "SOURCE / JAVADOC" y son opcionales y sirven principalmente para ser amigables con el desarrollador al codificar?
pushya

1
@pushya Lo más probable es que sí. Intentalo y ve que sucede.
Ian Roberts

15

Otra respuesta más pragmática con un ejemplo para ayudar a comprender la utilidad de lo classifiermejor.

Suponga que necesita dos versiones de un artefacto: para openjpay para eclipselink, por ejemplo, porque jar contiene entidades que se necesitan para mejorar la implementación de JPA específicamente.

Es posible que tenga un manejo diferente para estas compilaciones definidas en los perfiles de Maven y los perfiles utilizados también tienen propiedades <classifier />.

Para construir las versiones clasificadas de manera diferente, en pomel maven-jar-pluginse configuraría a continuación

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-jar-plugin</artifactId>
   <version>3.0.2</version>
   <configuration>
       <classifier>${classifier}</classifier>
   </configuration>
</plugin>

La instalación de ambos resultaría en archivos en repositorio algo como esto:

org / example / data / 1.0.0 / data-1.0.0.pom
org / example / data / 1.0.0 / data-1.0.0-openjpa.jar
org / example / data / 1.0.0 / data-1.0. 0-eclipselink.jar

Ahora solo sería cuestión de classifiercuál uso, así que para OpenJPA, por ejemplo:

<dependency>
   <groupId>org.example</groupId>
   <artifactId>data</artifactId>
   <version>1.0.0</version>       
   <classifier>openjpa</classifier>
</dependency>

y para EclipseLink cambiaría el clasificador como:

<classifier>eclipselink</classifier>

¿Dónde puedo encontrar una explicación de esta sintaxis: <classifier> [openjpa | eclipselink] </classifier>
Alan Snyder

@AlanSnyder era solo un "atajo de codificador perezoso", no una sintaxis realmente funcional. Edité esa parte para que quede más claro. [openjpa|eclipselink]era solo un "selector" para elegir cualquiera.
pirho

7

Ejemplo de clasificador
Como motivación para este elemento, considere, por ejemplo, un proyecto que ofrece un artefacto dirigido a JRE 1.8 pero al mismo tiempo también un artefacto que todavía admite JRE 1.7. El primer artefacto podría estar equipado con el clasificador jdk18 y el segundo con jdk14 de modo que los clientes puedan elegir cuál usar.

Otro caso de uso común para los clasificadores es la necesidad de adjuntar artefactos secundarios al artefacto principal del proyecto. Si navega por el repositorio central de Maven, notará que las fuentes de los clasificadores y javadoc se utilizan para implementar el código fuente del proyecto y los documentos de la API junto con los archivos de clase empaquetados.


3

Permite distinguir dos artefactos que pertenecen al mismo POM pero fueron construidos de manera diferente, y se adjunta al nombre del archivo después de la versión.

Por ejemplo, si tiene otros artefactos en su repositorio (documentos, fuentes ...), puede hacer referencia a ellos y agregarlos a su proyecto como dependencia. en este código agregando el <classifier>sources</classifier>estamos obteniendo el archivo sources.jar del repositorio.

    <dependency>
    <groupId>oauth.signpost</groupId>
    <artifactId>signpost-commonshttp4</artifactId>
    <version>1.2.1.2</version>
    <type>jar</type>
    ***<classifier>sources</classifier>***
    <scope>compile</scope>
    </dependency> 

en realidad, le permite ubicar sus dependencias con un mayor nivel de granularidad.


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.