Adding jaxb-api in the pom of extended-tests

[pgrt]

Hi,

I am in the progress of packaging pdfbox-graphics2d in Debian. When doing this, I noticed that jaxb-api was not part of the pom file in extended-tests, which raises an error during the tests with openjdk-11. I think jaxb-api was part of previous versions of openjdk, which might explain why you have not seen this error before.

In case it might help, here is the suggested addition to the aforementioned pom file.

jaxb_in_test.txt

Cheers,
Pierre

[rototor]

Thanks for noticing this. I've added your fix.

Maybe a stupid question, but why are you packaging this for Debian? AFAIK all java applications usually use Maven/Gradle/... to manage the dependencies and include them in their build.

Also note: The extended-tests package was some quick&dirty way to include some tests which exposed a real bug. This is more like a "test-scratchpad", nothing else. In the 3.0 branch I deleted that module. (The 3.0 branch follows PDFBox 3.0, currently at alpha2, no idea when this will be finally released). I don't think that you should package the extended-tests as it has no real functionality.

[pgrt]

Hi,

Thanks for looking at my proposal!

Sorry, I should have said more about my goals. When we build software in Debian, the build does not grasp jars (or any binary) from the Internet as a classic Maven (say) build would. Instead, it looks for the jars in already Debian-packaged software. THis guarantees that all the software is built from source and provides:

• lighter source packages because they are stripped from the dependencies;
• sometimes lighter binaries because we don't have to bundle jars, instead we put the dependencies in the classpath. Using the dependencies mecanism of Debian, we make sure the packages with the needed jars are installed when the users install the package they wish.
  Btw, it can also have other advantages: recently there was the log4j vulnerability, we only had to update log4j in the Debian archive and we were done, as no software depending on log4j bundles it, linking is only done at runtime through the classpath.

Thanks for the precision about extended-tests; I figured out it was a series of (deeper?) tests to do at build time, so I include it in the build to have the tests run, and then I don't include the jar in the Debian package.

I will be happy to provide further information if you want!

Best,
Pierre

[rototor]

Yes, it makes sense to not include the extended-tests jars in the package. Because there is really nothing to use. It was a chicken-and-egg problem: POI is using this library. To use POI to test some buggy behavior I need a project which includes POI as a test dependency - which can't be pdfbox-graphics2d itself, as POI depends on it... So I made this extended-tests.

Just being curious: What package in Debian is using my pdfbox-graphics2d?

[pgrt]

I see! Thanks for the explanation!

Sorry, I meant to mention it but forgot. This is KiNG [debianPackage], of which current Debian-packaged version 2.23.161106 does not need pdfbox-graphics2d... but it seems development is now active again and current upstream version [upstreamRepo] needs pdfbox-graphics2d.
This is why I am in the progress of packaging pdfbox-graphics2d in Debian to be able to upgrade king in Debian!

[debianPackage] https://tracker.debian.org/pkg/king
[upstreamRepo] https://github.com/rlabduke/javadev

[rototor]

Ah I see. So this project was the missing piece for KiNG to get rid of itext. But hopefully you will use a current version of this library. The one included in KiNG is a little bit outdated...

[pgrt]

Yes, I intend to use your latest tagged version! I made some tests, it is perfectly fit for building and running KiNG :-)