Update to use OpenPDF 1.0.5 and remove dependency on patched iText 2.1.7.js6 version

[ghost]

jasperreports depends on a patched version of iText:
https://github.com/TIBCOSoftware/jasperreports/blob/master/jasperreports/pom.xml#L240

The patched iText is used here:

jasperreports/jasperreports/src/net/sf/jasperreports/engine/export/JRPdfExporterTagHelper.java

Line 587 in 5af03d6

// the following method is part of the patched iText

Please submit the patch of iText upstream to OpenPDF here:
https://github.com/librepdf/openpdf

Then update the pom file of jasperreports to use OpenPDF 1.0.5 instead of the patched library.
Then jasperreports can depend on a maintained version of this library.

<dependency> <groupId>com.github.librepdf</groupId> <artifactId>openpdf</artifactId> <version>1.0.5</version> </dependency>

[albfernandez]

Patch is already commited and merged into OpenPDF

LibrePDF/OpenPDF#58

You can review to double-check if the patch is correct.

The changes are not yet released, so we have to wait until next OpenPDF release.

[ghost]

OpenPDF 1.1.0 has been released, with these changes included:

https://github.com/LibrePDF/OpenPDF/releases/tag/1.1.0

[azmathussainhotmailde]

Is this branch stable, I can generate PDFs without iText, but with OpenPDF ?

[PaulCormier]

I was having some issues with OpenPDF as a substitute to iText. I've submitted a PR which seems to fix the issue. I'll keep testing JasperReports 6.7.0 with OpenPDF 1.2.7-SNAPSHOT.

[andreasrosdal]

OpenPDF 1.2.7 has been released.

[bhansali-mukesh]

I have seen latest jasper report which is 6.10.0 , is still depending on iText 2.1.7
Can we use Open PDF instead of iText for Jasper Report ?
If Yes, Do we have a way to delegate PDF generation to open pdf ( or any other library ) ?

[douph1]

We use jasper 6.10.0 and maven artifact com.github.librepdf:openpdf:1.3.11 without notice any bug since some day. As openpdf use the same package name as itext com/lowagie there no problem to change dependencies.
We do it with gradle with resolutionStrategy
if (details.requested.group == 'com.lowagie' && details.requested.name == 'itext' ) {
details.useTarget group: 'com.github.librepdf', name: 'openpdf', version '1.3.11'
}

[teodord]

For now, I think we are going to stay with our own fork version of iText 2.1.7, as there is no strong reason to switch to OpenPDF. Especially since anyone can deploy OpenPDF instead of iText and JasperReports would work.
When the situation will change in the future, we'll reconsider.

[jansohn]

@teodord can you please elaborate why staying with an unmaintained dependency is preferred over switching to an actively maintained dependency? Especially if there are no migration costs whatsoever?

[jtjeferreira]

For whoever this might interest I tried to use OpenPDF instead of iText and had to revert because of this issue LibrePDF/OpenPDF#330

[teodord]

@teodord can you please elaborate why staying with an unmaintained dependency is preferred over switching to an actively maintained dependency? Especially if there are no migration costs whatsoever?

We maintain our "fork" of iText to the best of our ability and to the extent that it serves our needs. So far, we did not have to do much. Not sure what exactly you mean by "staying with", since at least for now OpenPDF has the same API and the same package names and class names as original iText so whoever wants to use OpenPDF instead of iText can do that easily.

[jansohn]

@teodord can you please elaborate why staying with an unmaintained dependency is preferred over switching to an actively maintained dependency? Especially if there are no migration costs whatsoever?

We maintain our "fork" of iText to the best of our ability and to the extent that it serves our needs. So far, we did not have to do much. Not sure what exactly you mean by "staying with", since at least for now OpenPDF has the same API and the same package names and class names as original iText so whoever wants to use OpenPDF instead of iText can do that easily.

For me that still doesn't explain why you prefer to stay on your "unmaintained" version of itext when there is a replacement available which is actively maintained and has a friendly license.
Of course I can change to OpenPDF explicitly but 99% of the jasperreport users probably don't even know about this and will unknowingly stay with the old itext version.
You would also get rid of issues like this #148 btw.

[arnonuem]

We use jasper 6.10.0 and maven artifact com.github.librepdf:openpdf:1.3.11 without notice any bug since some day. As openpdf use the same package name as itext com/lowagie there no problem to change dependencies.
We do it with gradle with resolutionStrategy
if (details.requested.group == 'com.lowagie' && details.requested.name == 'itext' ) {
details.useTarget group: 'com.github.librepdf', name: 'openpdf', version '1.3.11'
}

Thanks @douph1 this was an amazing hint. It took me some minutes to figure out how this works with kotlin script but finally i was able to run everything using this:

configurations.all {
    resolutionStrategy.eachDependency {
        if (this.requested.group == "com.lowagie" && this.requested.name == "itext" ) {
            this.useTarget("com.github.librepdf:openpdf:1.3.11")
        }
    }
}

[wng97]

hi,

We use jasper 6.10.0 and maven artifact com.github.librepdf:openpdf:1.3.11 without notice any bug since some day. As openpdf use the same package name as itext com/lowagie there no problem to change dependencies.
We do it with gradle with resolutionStrategy
if (details.requested.group == 'com.lowagie' && details.requested.name == 'itext' ) {
details.useTarget group: 'com.github.librepdf', name: 'openpdf', version '1.3.11'
}

Hi @douph1 ,
can you teach me how to convert the itext to openPDF i tried this one under:

configurations {
//    agent
    developmentOnly
    runtimeClasspath {
        extendsFrom developmentOnly
    }

    resolutionStrategy {
        if (this.requested.group == 'com.lowagie' && this.requested.name == 'itext' ) {
            this.useTarget group: 'com.github.librepdf', name: 'openpdf', version '1.3.11'
        }
    }
}

but it pop up this error

Could not get unknown property 'requested' for project ':server' of type org.gradle.api.Project.

and i not sure what is the requested.group and .name is used for TT

[douph1]

Hi, I use "Exemple 2" from https://docs.gradle.org/current/userguide/resolution_rules.html
or you'd better ask on gradle mailing list for support

[wng97]

@douph1 thanks a lot buddy :)

[nickcaballero]

Using dependency substitution:

    configurations.all {
        resolutionStrategy.dependencySubstitution {
            substitute(module('com.lowagie:itext'))
                    .using(module('com.github.librepdf:openpdf:1.3.11'))
        }
    }

[Bluejanis]

How can we use the OpenPdf version instead of the custom maintained itext version when using maven?

[nickcaballero]

@Bluejanis You can exclude the transitive iText dependency when declaring the jasperreports dependency using <exclusions> and then add the OpenPDF dependency separately.

https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html#dependency-exclusions

Apparently, you can also remove the iText dependency globally using banned dependency rules.

https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html

[mpretzer]

@teodord

We maintain our "fork" of iText to the best of our ability and to the extent that it serves our needs.

Where is the current version of that forks source code? According to the License contained in the current jasperreports release, it should be at http://jasperreports.sourceforge.net/maven2/com/lowagie/itext/, but it's not.

Have the XXE vulnerabilitities present in old iText versions been fixed in your fork? OpenPDF fixed them..

See also #188

[dadza]

We're looking into switching to OpenPDF but we're blocked by LibrePDF/OpenPDF#676

[teodord]

We are currently using a fork of OpenPDF because of the above mentioned bug.

[jansohn]

We are currently using a fork of OpenPDF because of the above mentioned bug.

Why not create a PR in the original project?

[dadza]

There's already a PR at LibrePDF/OpenPDF#765

We have a different/simpler fix in our patched version, once the PR above is accepted we would be able to use a vanilla OpenPDF release.