Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

207
Vistas
Diferencia de Gradle / Maven en el rango de versiones de tratamiento

Estoy usando la biblioteca QR-Bill v2.5.3 . Como una de sus dependencias, especifica PDFBox usando el rango [2.0.0,3.0) :

 <dependency> <groupId>org.apache.pdfbox</groupId> <artifactId>pdfbox</artifactId> <version>[2.0.0,3.0)</version> <scope>runtime</scope> </dependency>

Con un proyecto de Gradle, la dependencia se resuelve en pdfbox-2.0.24 . Con un proyecto Maven, se resuelve en pdfbox-3.0.0-RC1 .

¿Maven y Gradle realmente tratan los rangos de versión de manera diferente? ¿Cuál sería el rango correcto para la biblioteca para que tanto Gradle como Maven usen la última versión 2.x de PDFBox pero no usen la versión 3.x (ya que es incompatible)?

Más detalles de depuración:

Proyecto Maven

https://github.com/manuelbl/SwissQRBill/tree/master/examples/maven_example

 % mvn dependency:tree [INFO] net.codecrete.qrbill:maven-example:jar:1.0-SNAPSHOT [INFO] \- net.codecrete.qrbill:qrbill-generator:jar:2.5.3:compile [INFO] +- io.nayuki:qrcodegen:jar:1.7.0:runtime (version selected from constraint [1.6.0,2.0)) [INFO] \- org.apache.pdfbox:pdfbox:jar:3.0.0-RC1:runtime (version selected from constraint [2.0.0,3.0)) [INFO] +- org.apache.pdfbox:fontbox:jar:3.0.0-RC1:runtime [INFO] \- commons-logging:commons-logging:jar:1.2:runtime

proyecto gradle

https://github.com/manuelbl/SwissQRBill/tree/master/examples/gradle_example

 % gradle dependencies --configuration runtimeClasspath runtimeClasspath - Runtime classpath of source set 'main'. \--- net.codecrete.qrbill:qrbill-generator:2.5.3+ -> 2.5.3 +--- io.nayuki:qrcodegen:[1.6.0,2.0) -> 1.7.0 \--- org.apache.pdfbox:pdfbox:[2.0.0,3.0) -> 2.0.24 +--- org.apache.pdfbox:fontbox:2.0.24 | \--- commons-logging:commons-logging:1.2 \--- commons-logging:commons-logging:1.2
over 4 years ago · Santiago Trujillo
2 Respuestas
Responde la pregunta

0

Los estados de implementación de pedidos de Maven que las versiones alfa, beta y RC son menores que una versión real. Es por eso que ves que ocurre este comportamiento.

Entonces, en la práctica, pdfbox-3.0.0-RC1 < pdfbox-3.0.

Para excluir completamente la versión 3.0, debe excluir la primera versión preliminar. Algunas formas en que puedes lograrlo:

[2.0.,3-alfa)

[2.0.0,3.0.0-alfa2)

Otra opción, que no es ideal, es especificar el límite superior del rango como la última revisión de la versión 2.x:

[2.0.0,2.0.24]

Esta última opción está lejos de ser buena porque si Apache lanza una revisión de 2.x llamada 2.0.25, Maven no la incluirá.

over 4 years ago · Santiago Trujillo Denunciar

0

Basado en la respuesta de Diego M., aquí hay información adicional:

El requisito de la versión [2.0,3.0) no parece tener sentido nunca:

  • La intención típica es restringirlo a todas las versiones 2.*. Sin embargo, Maven también incluye todas las versiones preliminares de 3.0. No puedo imaginar un caso en el que esto sería útil.
  • Maven y Gradle lo interpretan de manera diferente. Por lo tanto, no es adecuado cuando se usan ambas herramientas, en particular cuando se publica en Maven Central.

El mejor requisito de versión para restringir a las versiones 2.* es: [2.0,2.999999] .

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda