Free the Slaves: Pentaho Charting Expressions are now a independent project

Charting in the Classic-Engine is currently implemented as a set of report functions and expressions. A chart-collector function produces the data-set and a chart-expression then uses the dataset and produces a JFreeChart object for it. The JFreeChart object is then directly renderable by the reporting-engine and produces some nice Vector-graphics output.

For historical reasons, these charting expressions have been held captive by the Pentaho-Platform. In the early days, when the land was rough and largely unsettled, a important project required to include charts. As some of the demos in the old JFreeReport-extensions project showed how to integrate JFreeChart into the reporting engine, it was the most obvious way to head into that direction. And so the first chart expression was born.

Over the years, more and more chart types were added and whenever a new feature was needed, it was added as well. At some point, the chart expressions started to depend on some core classes of the Pentaho-Platform, and thus what started as “strange packaging strategy” suddenly became a severe dependency issue, as now the chart-expressions were unable to run without a configured platform in the back. This rendered these expressions unusable outside of the platform and thus unusable for anyone who used the reporting-engine as embedded component.

Fast forward. Some months/years later, the trouble-maker dependency has been removed. But sitting in the same project as the platform code, there are only policies and documentation notes that protect us from having such a rouge dependency again. And in the real world, policies and documentation hints do not actively protect the code – they just make the reasoning for having to fix the newly introduced flaw easier.

But the new found peace was still an uneasy one: Changes in the way the reporting engine handled functions and generated content propagated slowly into these expressions (as the release cycles of the Engine and Platform do not (and cannot) match). At the same time, new properties of the expressions were added, which somehow appeared to work (well, they did not crash 🙂 ) with the older engine but due to stricter validity checks on the existing contracts were bluntly rejected in the later engine and report-designer. And there the release cycle hit again: We did not see the troublesome contribution until the first bug-report came in. At that particular point, a fix would have either broken the engine’s or the platform’s backward compatibility promise.

And of course: Adding code to a large monolithic project is a lot more cumbersome than adding code to a small and simple (the Chart-Expressions are not simple. Although they have not yet reached the gnomish-threshold, the massive amount of knobs and levers and other properties in them makes them a complex system) focused project.

So let’s see what we have:

  • The chart-expressions share no code with the platform and do not depend on the mere existence of the platform
  • The shifted release cycle gives me headaches
  • Adding code to a heavyweight project is no fun

So let’s fix these problems.

There is now a new project in the reporting-engine Subversion-Repository under svn://source.pentaho.org/pentaho-reporting/engines/classic/legacy-charts
The project contains a copy of the chart-expression formerly found in the platform. With Platform 1.8, the platform JAR will no longer contain the chart-expressions and the sources for them will be removed from the platform-project. The platform then switches to the expressions found here.

The first official release of these expressions will be named version 0.8.10 (to be in sync with the reporting-engine).

The freed chart-expressions take 72 KB (compared to ~450 KB of the pentaho-plugin.jar) and stick with JDK 1.4 (they _should_ even work with JDK 1.3), instead of requiring the bloatware JDK 1.5.

As initial bonus for early adopters, all chart-expressions now can control the item-label’s visibility and handle null-values and invalid datasets a lot more gracefully than before.

This entry was posted in Development on by .
Thomas

About Thomas

After working as all-hands guy and lead developer on Pentaho Reporting for over an decade, I have learned a thing or two about report generation, layouting and general BI practices. I have witnessed the remarkable growth of Pentaho Reporting from a small niche product to a enterprise class Business Intelligence product. This blog documents my own perspective on Pentaho Reporting's development process and our our steps towards upcoming releases.