1) Upgrade our jfreereport externals 2) Check that reportbuilder didn't break Sources: https://github.com/pentaho/pentaho-reporting http://jfree.org/jcommon/ Theoretically should be on http://sourceforge.net/projects/jfreereport/files/, but could not find sources there (only compiled class files).
In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval. Thank you and apologies for the noise
Adding self to CC if not already on
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyBeginner SkillScript TopicCleanup) [NinjaEdit]
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
Re-evaluating the EasyHack in 2022 I think this is relevant as the reported versions are quite old. $ cat external/jfreereport/version.mk FLUTE_VERSION=1.1.6 LIBBASE_VERSION=1.1.6 LIBFONTS_VERSION=1.1.6 LIBFORMAT_VERSION=1.1.6 LIBFORMULA_VERSION=1.1.7 LIBLOADER_VERSION=1.1.6 LIBREPOSITORY_VERSION=1.1.6 LIBSERIALIZER_VERSION=1.1.6 LIBXML_VERSION=1.1.7 The application is now called Pentaho reporting: https://github.com/pentaho/pentaho-reporting On the other hand, there is a little chance that this task would be easy because it is now several years behind of the latest version.
IMHO, it doesn't worth it to upgrade, it should rather be closed. Indeed, we need another tool not dependent from Java since Java dependency is forbidden in Appstore. See https://bugs.documentfoundation.org/show_bug.cgi?id=151250#c4
(In reply to Julien Nabet from comment #6) > IMHO, it doesn't worth it to upgrade, it should rather be closed. > Indeed, we need another tool not dependent from Java since Java dependency > is forbidden in Appstore. > See https://bugs.documentfoundation.org/show_bug.cgi?id=151250#c4 C++ solution exists: https://github.com/fralx/LimeReport https://limereport.ru/en/ Discussion in the wiki: https://wiki.documentfoundation.org/Development/Under-loved_areas#Replace_Java_report_generator_code I asked Noel and he thinks it's feasible to use.
Just as a data point: > C++ solution exists: > https://github.com/fralx/LimeReport > https://limereport.ru/en/ Tried/looked at that. That a) needs Qt, thus we get a strict dependency on qt for the report builder packages (or people ship Qt, too as an internal library..) b) creates $ find . -name "*.so*" ./liblimereport-qt5.so ./build/5.15.6/linux64/release/lib/libQtZint.so which sucks and would mean shipping it internally as there is no SONAME to rely on to make it be used system-wide without breaking. In this regard even the jfreereport libs are better if you have the versions under control (all of them are used from the system in Debian), even though admittedly they are bad because being Java ;-)