iReport vs. version control

Tried to include a JRXML string variable with "$Revision$" as initial expression. It's impossible to have such a string, as "$" is expected to start something JRXML specific like a field, a variable (itself!!), a paramater. And including a backslash "\" destroys the idea resp. the effect.
So: no RCS / CVS / subversion strings in JRXML. Alright within XML comments they work. But then: you never know for sure, what iReport does with your XML comments. With any future release they may decide to remove XML comments. Then you are pissed.

counting the elements within a group

If you created a group by the name of this_group, you also created a counter for the elements within that group by the name of this_group_COUNT, i.e. a variable.

editing JRXML in emacs using nxml-mode

Just created an RELAG-NG ("compact") grammar for editing JRXML files.

I used trang for that, and the "input module" was a sample JRXML file. Yes, that means: occasionally some JRXML file will have tags or attributes, that my jasperreport.rnc does not know yet. But then re-running trang on an additional sample file is not really a big job.

I really love editing XML.

I re-ordered and "grouped" the XML pieces for the elements in my sample reports. That helps to clean up some things, that got a little messy over the time. In the end you recognize, how much duplicate code you have.

You may want to fight the redundancy problems through JRXML subreports.
I actually made my JRXML a "here document" for a shell script. A couple of hours later I knew, that a perl script is the better approach. Another couple of hours later there were plenty little parameterized "here documents". I have solved my redundancy problem here through "looping over lists of configurations".

postbank.de and JasperReports

When I drew my current account statement today, I was curious and applied the "pdfinfo" command on it. I was quite astonished, when it said this:

Creator: JasperReports (kontoauszug)

Producer: iText 1.4 (by lowagie.com)

I went back to their first PDF statements in 2006, and they said just the same.
Of course I would like to get in touch with them and find out, whether the knowledge, that I acquired recently in that area, could be of any use.
Yes, of course, there is no obvious current need for them to change anything regarding these account statements, but ...
Postbank has alway only been providing non-business customers with PDF account statements.
And they have been promising for years now, they wouldn't keep neglecting business customers forever ;-)
I guess that has to do with extended legal needs, e.g. signed PDF and so forth.

Right, I shouldn't forget mentioning this:
During the last couple of months I extended demo/samples/text/TextApp.java so that I can call all the necessary steps (JRXML->.jasper, filling into a .jrprint file, creating e.g. PDF) within a single call to this utility. You can now also pass JRXML parameters to this utility.
So using that simple utility you can create PDF reports in a batch run, starting from a JRXML or ".jasper" file and a database connection without any big software around -- just the JARs, that this utility needs.

my 1st steps in Java: extending a JasperReport sample program using Apache Commons CLI

iReports and JasperReports (and also JasperETL and much more) are open source software, that you can find on JasperForge.org.

I intended to extend jasperreports-3.6.2/demo/samples/text/TextApp.java, so that it would take "-Dname=value" style options. There was a need to make TextApp.java a little more flexible, and that was quite easily to achieve making use of getProperty calls.

A friend had given me the hint recently to have a look at "System.getProperty()", but it turned out to only provide the caller with properties like "os.name", according to http://java.sun.com/docs/books/tutorial/essential/environment/sysprop.html. So that wasn't quite the route to follow.


I started my day googling for "getopt java", found that nice package "Apache Commons CLI", made use of it within that JasperForge utility, and started scripting a batch run around that utility's targets named "fill..." resp. "text..." in bash, resp. their new sisters, that I derived from them today. Next step is to rewrite that shell script as Windows batch script file resp. as python script to be used in a Windows environment. This work is almost "production ready", but I am facing quite some necessary paperwork, so that the software developed can get made serious use of.

Looks like the Jasper guys had not expected their software to be used like that. The ".jrxml" gets designed using iReport on a Windows box or whatever; after that it is being made use of on any kind of server executing Java classes with access to a database. (I wonder, whether that approach would also work with JasperETL.)

I am quite satisfied with my 1st steps in Java in that JasperReport environment.

I really had no idea and also no perspective of getting thrown into Java development during a commercial project, and even in the context of JasperReport. I do like this.

Update / 2010-03-05:
The atomar production steps described within TextApp.java's build.xml are rather nice and instructive, but they make use of those routines within TextApp.java, where target file names (incl. directory path) get strictly derived from source file names. I added resp. derived productions steps, that make use of thoses methods of the API, that allow you to name the destiny's name explictily. And I also added chains of productions steps into the java source file, so that the calling shell resp. "whatever" script wouldn't have to deal with calling the chained steps one by one itself. So far there are chains starting at .jrxml and at .jasper, and chains that end at .txt and also at .pdf. The idea is to place intermediate files on local disks within temp. directories instead of close to the source resp. final target file (maybe) somewhere on a network file system.