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

Sun, 11 May 2008 09:35:00 GMT

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.

Things that should never have existed in the first place

Sat, 31 Mar 2007 18:22:00 GMT

Pentaho Reporting never had real charting support. Although JFreeChart, the reference project for Java-based charting, was developed next door, we never came to the point where users could have added charts to a report.

The engine itself is able to render Drawable-objects. Drawables are objects that know how to render themselves to a Graphics2D context. This interface was defined by JFreeChart as simple abstraction layer for its components. So the only way to get charts into the report, was to print them as drawables. If you wanted charts based on the data from the report, you would have to create a function that collects the data and finally creates the JFreeChart instance, which then could be printed in the report.

This story is sick, I know. But we haven't even reached the end yet.

When Pentaho elected JFreeReport to be the primary Reporting Engine for their plattform, they also asked about charting. Naive as I was, I mentioned that sick way of getting charts into the report. Even worse, I've created a working sample-report for them so that they can see it working.

Oh, I should have known better. Every sin gets punished sooner or later, and my punishment is called 'ChartExpression'. The prototype actually evolved into a couple of function implementations. The Pentaho folks still think, that this was a natural evolution born out of the need for at least some charting capabilities. But I know better: The gods of good software architecture were really pissed of at me, just for creating that abnomination. If there were some deserts near by, you would now see me heading of for a 40 year tip to nowhere, just to end my life directly in front of the promised land.

So all you developers out there: If someone asks you for a quick solution for a problem, and all you could deliver is an architectural nighmare: turn them down. Tell'em: 'No way! There is no possibility how this can be done right now.'

If you feel lucky, you might even ask them for a project budget to develop something sane.

But never ever say the unholy sentence: "Sure, we can build something quick and dirty. We'll create a better solution as soon as we find more time for it."

That time will never come ...

Reporting Tales - chart tag

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

Things that should never have existed in the first place