LibDocBundle - Pentaho Reporting meets ODF

One of the main problems with dealing with report-definitions we encountered during the last year was the ugly and error prone process of deploying (or in Pentaho Speak: publishing) reports to a server or applications.

Many report-definitions consist of several files - the main XML-file, images, sub-report and data-source definitions and resource-bundles for the report localization. Keeping all these files in sync and dealing with them without running into conflicts was more art than science.

Our release plans include some heavy refactorings to the file format to allow the report-designer, report-wizard and engine to share a single file format. Going forward with creating just a bunch of new XML-schemas would have worsen the problem to the point where we - as developers - would have to work around the bugs caused by that file-system chaos instead of spending time for useful developments.

One major truth in software engineering is: No matter what your problem is, someone else probably solved it already. So instead of thinking of a new and overly fancy way to create a container file-format, we just have to look around how other systems asdress these problems.

Looking to Microsoft, Business Objects and most other "old" vendors yielded no usable results. Using obscure binary formats like OLE-containers might have been a good idea in the last century, but as we dont intend to build yet another island solution, we quickly forgot about that path.

But if you followed the news, then the solution is rather obvious: The OpenDocument  file format (ODF) used by OpenOffice and others provides a good framework for storing document content. But ODF is more than just storing some files in a ZIP file.

The ODF-Archives contain a standard way of describing document wide meta-data, the structure of the archive is well defined and the standard even provides means to encrypt the contents of the file.

Although we do not intend to implement (or use) the core XML schema defined for the actual document contents, the supporting framework around that format is to good to miss.

After two weeks of studying, planing and coding, we are now able to show the first result on our long way to version 1.0.

It Just Works(tm): Plug-and-play bundle reading

LibDocBundle hooks seamlessly into the LibLoader and LibRepository libraries and provides transparent access to the documents inside the ZIP file. An application that used to work with XML files directly now can work with the ZIP-archives in exactly the same way. There are no changes to the code needed - just point your "File-Open" dialog to the zip-document-bundle instead of the raw-xml file and it "just works(tm)".

Of what use is a good standard, if it is to complicated to be implemented easily

For bundle-editing applications like the report-designer or report-wizard, LibDocBundle also provides bundle-implementations and utility classes which make it easy to create standard-conforming document bundles.

And now that we have a clean storage container, lets fill it with life. Next stop: The Unified XML file format.

Classic Engine 1.0 Development started

Now that we finished the second bug-fix release for the current stable version of the Pentaho-Reporting Classic-Engine, we are now starting with the work on the Classic-Engine 1.0.

For the next six month you will see a lot of changes to this good old engine.

The first (and maybe deepest) change is already complete. Since last week the engine and all libraries are free of any dependencies to JCommon. David Gilbert and I came to the conclusion that JCommon is becoming now a trouble-maker instead of a nice and lovely helper. The two main projects using JCommon are JFreeChart and Pentaho-Reporting. However, the amount of JCommon-code used by both projects at the same time is minimal. Therefore it is safe and sane to let JCommon rest in peace.

The upcoming JFreeChart 2.0 will no longer use JCommon, all classes used by JFreeChart have been moved under the org.jfree.chart package space.

In the Pentaho Reporting libraries we make heavy use of this library - so just copying the code would not work for us. Therefore we spawned a new library called "libbase", which contains all the code for the base-services formerly provided by JCommon. The Configuration, Booting and Modularization code along with a small set of utility-classes now belongs to this library. While working on this we also fixed a couple of well-known bugs which were not easily fixable in JCommon itself.

While replacing JCommon, we also switched logging away from our own Wrapper-implementation to the Apache-Commons-Logging library. This library seems to be a good compromise between flexibility, space (it's jar is only 26kb) and interoperability (Commons-Logging happily runs with JDK 1.2.2 and also works with Log4J, which seems to be a common logging framework in server applications)

The next step on our roadmap is the Zip-Based document container, which then prepares our engine for the new "unified-fileformat" system.

Oh, if only everything would be so easy as coming up with big names for long awaited improvements :)