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.