JaspeReports is heralded as a great and powerful reporting engine, add to that iReport and a Grails Plugin and we’re all set to go. But beware the learning curve!
Sure you can fire up iReport, run the very nice wizard and have a report filled by a basic SQL query in only a few minutes. But we are using iReport because we want something more than a simple table view that we already have in Grails. We want charts, trend plots, column totals, grouping and all the export formats. Be prepared to spend at least 2 weeks just getting through the learning curve.
My manager popped his head in and asked how that report was going? I actually had to tell him I was trying to figure out how to do a page break! You’d think the page break on the palette would do the job but what I needed was another detail band.
If your time is worth real money then I highly recommend getting some training or purchasing a tutorial from Jasper Soft. Even then a fairly complex report is going to take half a day to build. There is good reason why Dynamic Jasper was written so try that out if your needs are more basic. If all you want is one or two pie charts then try using JFreeChart directly.
Because you’d be mistaken to think: “We’ll us a report builder, after the initial setup the managers will be able to write their own reports…”
The first major issue I had was that the grails plugin (0.9.7) came with rather old jar libs.
Put something like this in BuildConfig.groovy:
grails.war.resources = { stagingDir, args -> // Remove some duplicate jars. delete file: "${stagingDir}/WEB-INF/lib/jasperreports-2.0.5.jar" delete file: "${stagingDir}/WEB-INF/lib/jasperreports-3.1.2.jar" delete file: "${stagingDir}/WEB-INF/lib/aspectjrt-1.5.4.jar" delete file: "${stagingDir}/WEB-INF/lib/commons-digester-1.7.jar" delete file: "${stagingDir}/WEB-INF/lib/iText-2.0.8.jar" delete file: "${stagingDir}/WEB-INF/lib/iText-2.1.5.jar" delete file: "${stagingDir}/WEB-INF/lib/jfreechart-1.0.3.jar" delete file: "${stagingDir}/WEB-INF/lib/poi-3.0.2-FINAL-20080204.jar" delete file: "${stagingDir}/WEB-INF/lib/facebook-2.0.4.jar" } grails.project.dependency.resolution = { // inherit Grails' default dependencies inherits( "global" ) { // uncomment to disable ehcache // excludes 'ehcache' } log "warn" // log level of Ivy resolver, either 'error', 'warn', 'info', 'debug' or 'verbose' repositories { grailsPlugins() grailsHome() mavenCentral() } dependencies { // specify dependencies here under either 'build', 'compile', 'runtime', 'test' or 'provided' scopes eg. runtime 'mysql:mysql-connector-java:5.1.9', 'org.apache.poi:poi:3.5-FINAL' runtime ('net.sf.jasperreports:jasperreports:3.7.2') { excludes 'xml-apis' } } } |
Note: the exclude ‘xml-apis’ because your JVM will most likely supply a lib that conflicts with the one pulled in by jasperreports.
Now after a myriad of other hurdles have been crossed which I won’t bore you with, suffice to say that on one machine iReport runs very slooooowly. After a whole day googling and tweaking memory and lib settings it’s still the same and a few others have had the same problem, ok can’t use iReport on that machine.
We get to the List component and it works great once you understand it:
- It’s a mini sub report and gets its own dataset when you add it.
- You need to build this dataset with a datasource or connection expression:
new net.sf.jasperreports.engine.data.JRBeanCollectionDataSource($F{taskList})
In this case a list field from the main report is the source. - Then you need to add fields to the dataset just as you would in the main report
and place those fields inside the list component. - The same principals apply to charts, tables etc.
In concusion JasperReports is very powerful but with that comes some complexity so don’t expect to have it done and dusted in a day, there is a lot to learn. I also played with jasper server community edition during this time but since the reports we need are more complex a programmer needs to build them so they might as well just be included in the main application. See gnuMims for real life code examples.
Gavin Kromhout:
Thank you for visiting.
Do look around.
Do leave a comment.
JasperReports and iReport – The Learning Curve…
JaspeReports is heralded as a great and powerful reporting engine, add to that iReport and a Grails Plugin and we’re all set to go. But beware the learning curve!
Sure you can fire up iReport, run the very nice wizard and have a report filled by a …
Concerning the list component…we use it as well but we don’t succeed in stretching the list component according to it’s required size so that the subsequent elements (textfields, …) float in order not to overlap with the list component.
Did you succeed in that?
Jan
If I understand you Jan, then some components simply don’t auto stretch as one would like them too. This is part of what makes creating a robust Jasper Report harder than it could/should be. I find that I have to set the size of the list component and the fields to allow for the largest data that I expect to display. Play with the the stretch and wrap settings and try populating with a good example set of data to be sure that the report does not break in unexpected ways.
Gavin, yes you understood me correct. I didn’t find a way to make the list component stretch.
You propose setting the space according to the largest data one expects to display, this results in either
a) if you provide a lot of space for the list you will have much free unused white space in many cases, but it won’t overlap though
b) if you are less generous with the space for the list, it is more likely that the text will overlap if the list contains more entries
It is a way, but I guess somehow not satisfying, because almost every report that we will generate has a one-to-many relationship and thus will contain such a list, with a really dynamic number of list entries.
IMHO it’s a quite common requirement, I really wonder why there is no easy solution for this.
BTW: I crossposted in the jasper forum, but no answers yet (except mine 😉 http://jasperforge.org/plugins/espforum/view.php?group_id=102&forumid=103&topicid=92300
Hi Jan,
You are correct that this is not a very satisfying solution. Often I have to change the layout of the report completely from how I initially wanted/imagined it, to work around limitations like this. You can find a multi-page report chewing through a lot of paper/pdf pages otherwise. This can take may hours of trial and error as mentioned in my post. Other times I image (or have to copy) a single page ‘stamp’ report layout and get exactly what I want in a couple of hours.
Hi Gavin,
in the meantime I got it working as I need it to. Actually we even used the table component instead of the list component but the principle is the same.
In every textField contained in the table I set isStretchWithOverflow=”true”. On the elements that follow the table I set positionType=”Float” so they float accordingly to the additional space the table requires.
I was quite sure that I exactly tried that out before, but obviously I did something wrong…
Hi Jan,
Nice work thanks for sharing! Yes those properties seem to depend on the settings above them in the tree and even the page settings. So often have to check/try the whole lot from top to bottom.