Después de consultar expertos en esta materia, programadores de varias ramas y profesores dimos con la respuesta al dilema y la dejamos plasmada en este post.
Solución:
Una solución mucho más simple puede ser actualizar a una versión más nueva de jasperreports
. Versión 6.1.0
tiene esta dependencia en iText:
com.lowagie
itext
2.1.7.js2
compile
¡No más dependencia “flotante” en iText, y es una versión hecha a medida para jasperreports!
Consulte http://mvnrepository.com/artifact/net.sf.jasperreports/jasperreports/6.1.0 para obtener la información completa pom.xml
.
De hecho, el problema está en el POM de jasper-reports:
com.lowagie
yo texteo
[1.02b,)
compile
Jasper-reports distributes a (modified) build of iText 2.1.7
since at least November 2012 (if memory serves me well), so if your version of jasper-reports still has a dependency on 1.02b
and up, it must be a very old version.
The jasper-reports dependency on iText should be changed to:
com.lowagie
itext
[1.02b,2.1.7]
compilar
O solo:
com.lowagie
itext
2.1.7
compile
Esto se relaciona con esta pregunta: ¿Cómo le digo a Maven que use la última versión de una dependencia? Esa página está plagada de advertencias acerca de usar siempre la última versión para sus dependencias. Reduce la reproducibilidad de sus compilaciones.
2.1.7
fue la última versión de iText lanzada por la empresa iText Group NV (o su antecesor legal), con la com.lowagie
Identificación del grupo. La siguiente versión de iText, lanzada por la empresa iText Group NV, fue la versión 5.0.0
, con el com.itextpdf
groupId, lo que significa que es binario incompatible con su código actual. También está el asunto de un cambio de licencia a AGPL, pero eso está fuera del alcance de StackOverflow, quiero restringir mi respuesta a los asuntos técnicos.
Cualquier otra versión de iText entre 2.1.7
y 5.0.0
, me gusta 4.2.0
y 4.2.1
, son bifurcaciones de otras empresas. De acuerdo con la Guía de Apache para cargar artefactos en el Repositorio central (https://maven.apache.org/guides/mini/guide-central-repository-upload.html), esas empresas deberían haber usado un ID de grupo diferente, ya que la página claramente afirma en sus preguntas frecuentes:
Tengo una versión parcheada del proyecto foo desarrollado en foo.com, ¿qué ID de grupo debo usar? Cuando parchea/modifica un proyecto de terceros, esa versión parcheada se convierte en su proyecto y, por lo tanto, debe distribuirse bajo un ID de grupo que controle como cualquier proyecto que hubiera desarrollado, nunca bajo com.foo. Consulte las consideraciones anteriores sobre groupId.
TL; DR Si no desea cambiar su código, dígale a su Maven que solo obtenga iText 2.1.7.
estoy usando gradle y para la versión actual 6.8.2
Recibí el siguiente error de compilación:> Could not find com.lowagie:itext:2.1.7.js6
así que agregué http://jaspersoft.jfrog.io/jaspersoft/third-party-ce-artifacts/
como repositorio y ahora funciona.
repositories
mavenCentral()
maven url "http://jaspersoft.jfrog.io/jaspersoft/third-party-ce-artifacts/"
dependencies
compile 'net.sf.jasperreports:jasperreports:6.8.0'
Aquí puedes ver las reseñas y valoraciones de los usuarios
Si tienes alguna incertidumbre y disposición de arreglar nuestro ensayo te recomendamos realizar un exégesis y con deseo lo observaremos.