Closed jstaerk closed 3 months ago
good issue - any release plannings for this?
I would like to have it in the next release, 2.12.
But it depends a bit how it behaves and how other people act. If there e.g. were a new ZUGFeRD release in june I might want to follow up with a new mustang version in maybe the two weeks thereafter.
The test output is currently
[ERROR] Tests run: 70, Failures: 9, Errors: 15, Skipped: 0
And the pdf input pre-validation is now stricter. If it weren't we would be down at 7 Failures 11 Errors. One plan is to remove the input pre-validation from the "library" component altogether, but leave it in the "validator" component. In which case it could be verapdf based, which would at least remove the puzzling effects that occur when the pdfbox based input validation reports different errors than the (often better) verapdf based "output" validation.
But there's also different things, PDF files which could previously be read and now seem to be no longer understood. I'm investigating...
I understand. If I can help you with testing some PDF files with PDF Box 3.x, I've tons of PDFs from different ERP Systems like SAP, NAV, BC, Lexoffice, ...
I might also have a problem using mustang related to its pdfbox dependency not being version 3.x. Since I have a separate use of pdfbox version 3.x in my project, there are dependency conflicts with the version in mustang.
When trying to load the pdf via:
ZUGFeRDExporterFromA1 ze = new ZUGFeRDExporterFromA1().load("MustangGnuaccountingBeispielRE-20190610_507blanko.pdf");
from the example, it caused an error:
java.lang.NoClassDefFoundError: org/apache/pdfbox/io/RandomAccessBufferedFileInputStream
.
Resolving the conflicts with dependencyManagement didn't work due to breaking changes I think.
Initial proposal in #393
What do you mean initial proposal? You must have spend days, that fixed the whole project and maybe more #372 #337
no more compile errors, now fixing the tests