byteryder

I had the same problem, with a subreport repeating on every page. I had checked "print when detail overflows" for the subreport in the master report. When I unchecked it, the problem was solved. The idea of using a REPORT-COUNT == 1 is good if you are only going to print the detail band once. If you are going to repeat the detail (which happens in my report), then this doesn't work.

It appears you are having a class loader problem. I'm not able to help because all my experience is with eclipse and I'm not familiar with the structure of IntelliJ. Perhaps someone else here might be able to help, or maybe there is an IntelliJ forum where you could ask the question. Sorry and good luck!

I wasn't able to open either of your attachments. However, the error you reported refers to the spring-core .jar file. I suspect the .jar isn't on the class path.

hoopla, I have the same problem. I was updating my Java (eclipse rcp) application because the new gtk2 (Linux) broke my application widgets. I updated to eclipse version 3.6.0 and JasperReports 3.7.1 and got the error message (see attached). Nowhere do I see a dependency on Spring mentioned for JasperReports - not the web, Heffelfinger's "JasperReports 3.5 for Java Developers", or "The Definitive Guide to JasperReports", so we appear to be undocumented waters. Glad to see you found the solution (I was about to try it myself). I agree, it would be nice if someone responded about the current JasperReports dependencies.

I've found the solution and, since others have viewed this thread, thought it would be helpful to post it here. Frames do allow grouping of fields and some control of stretch behavior, but there is an easier and more effective way. The 2007 "Definitive Guide" mentions that elementGroup is specifically used to control stretch behavior. This feature allows grouping one or more variables, it can be nested, and it is easy to use. I was able to try a couple of different grouping strategies and got rid of the extra spaces in my report. So, that's the fix!

asejas, thanks so much for the insight. I placed my fields in frames and things improved but it wasn't a total fix. I changed the background color on the frames so I could see exactly what was happening. If the Title field (enclosed in a frame) is 1 line, all is well. If the Title field is 2 or 3 lines, bad things happen. The "Non Journal Frame" is expanded and printed, and space is added after this frame. The "Non Journal Frame" contains three null fields and should not print. The space added after this frame shouldn't happen at all, of course. I tried setting a "print when" condition for the "Non Journal Frame" and it didn't help. I'm surprised at the problem, because JasperReports is pretty sophisticated and mature, and this seems like a simple thing to do. I tried setting a "print when" condition for the "Non Journal Frame" and it didn't help. Any additional thoughts would be welcomed. The jrxml file is attached.

I'm running into a problem with stretching fields using iReport 3.7.1 on Linux (Ubuntu 9.10). I have a simple detail band that includes five text fields that are set to stretch. Except for the Title field, they can be null, set to blank when null, and set not to print when blank. Here's the problem. On records where the Title field is 1 line, preview looks perfect. When Title stretches to 2 lines, the subsequent field (Journal) also stretches to two lines. There is extra space where the subsequent stretch fields are positioned, even though they are all blank and no line should be printed. I've tried adjusting the field height, including 0, and the same happens. I've included a portion of the detail band including the first four fields. I also included the entire jrxml and style files for brave souls that take an interest in this problem. Any thoughts? Thanks so much! Code:<band height="204" splitType="Stretch"><textField> <reportElement style="Monospace10" x="0" y="0" width="552" height="12" isPrintWhenDetailOverflows="true"/> <textElement/> <textFieldExpression class="java.lang.String"><![CDATA[$V{RefType}]]></textFieldExpression></textField><textField isBlankWhenNull="true"> <reportElement style="Monospace10" x="0" y="12" width="552" height="12" isRemoveLineWhenBlank="true" isPrintWhenDetailOverflows="true"/> <textElement/> <textFieldExpression class="java.lang.String"><![CDATA[$V{RefYear}]]></textFieldExpression></textField><textField isStretchWithOverflow="true" pattern="" isBlankWhenNull="true"> <reportElement key="" style="Monospace10" positionType="Float" stretchType="RelativeToBandHeight" x="0" y="24" width="552" height="12" isRemoveLineWhenBlank="true" isPrintWhenDetailOverflows="true"/> <textElement/> <textFieldExpression class="java.lang.String"><![CDATA[$V{RefTitle}]]></textFieldExpression></textField><textField isStretchWithOverflow="true" isBlankWhenNull="true"> <reportElement style="Monospace10" positionType="Float" stretchType="RelativeToBandHeight" x="0" y="36" width="552" height="12" isRemoveLineWhenBlank="true" isPrintWhenDetailOverflows="true"/> <textElement/> <textFieldExpression class="java.lang.String"><![CDATA[$V{RefJournal}]]></textFieldExpression></textField>

Thought others might benefit from my recent experiences. I have an eclipse RCP desktop application that has a JDBC database as its data source. Reporting is done with JasperReports (JR) and swtJasperViewer. A couple of years ago, selecting JR over BIRT was easy because BIRT was pretty rudimentary. Since then, BIRT has improved greatly, but JR has also been refined. I've recently revised my app and considered switching to BIRT. I read the tutorials and one of the books (two are now available), played with BIRT, and decided to keep JR. Here's why. BIRT documentation has improved greatly, to the point it is now usable. JR documentation,whiile not great, is sufficient. The Heffelfinger book is relevant to the current version and is helpful. In this area, I judge BIRT and JR tied. Both have GUI report designers. JR's iReport is cross-platform compatible while the BIRT standalone designer is available only for Windows; an interesting choice by the open-source eclipse project. To use the BIRT report designer in Linux, I had to download a full eclipse SDK. Both work well, so I think this is also a tie. Both have viewers that can be incorporated into an RCP application. The BIRT viewer has basic functionality but swtJasperViewer has a better "print" feature and the zoom feature is very useful. Definite edge to JR. The code to incorporate JR and swtJasperViewer into an RCP application is simple and straightforward. BIRT is a bit more complicated. The BIRT documentation focuses largely on incorporating it into a Web app, not a desktop app, so for this purpose it is really no better than the JR documentation. Edge to JR. BIRT is now able to export to a couple more formats, including pdf, Excel, and Word 2003. Again, an interesting choice by eclipse to go with these proprietary formats rather than open-source standards. OpenOffice.org 3 Writer is able to read MS Word 2003 documents but I was not able to get it to read a Word 2003 file exported by BIRT that included a simple table. This may well be due to Microsoft, which has been known to change standards without warning. JR supports more formats, including pdf and rtf. Definite edge to JR.So, after experimenting with BIRT, I feel JR is still better for my type of project.

I was able to solve the problem, so will post this here in case others can benefit. I'm now using Java 1.6, eclipse 3.4.1. and iReports 3.5.2. I looked into the iReports program to see which versions of the various libraries were used there - some of them are not the most recent. Specifically, it uses commons-logging-1.1.jar, iText-2.1.0.jar, and commons-digester-1.7.jar. I downloaded these and used them in my eclipse rcp application, along with JasperReports 3.5.2 and swtJasperViewer 1.2.0. All is well. So, when JasperReports documentation lists its dependencies as version x.x or newer, that is only true up to a point.

I've updated an eclipse rcp application and am now getting missing data on my report when I recompile the .jasper files with version compatibility set at 3.5.1. My current versions are: eclipse 3.4.1, JasperReports 3.5.1, swtJasperViewer 1.2.0, commons-beanutils 1.8.0, commons-collections 3.2.1, commons-digester 2.0, commons-logging 1.1.1, iText 2.1.5, and JRE 1.6. My old reports (don't know the version but they were compiled in September 2007) work perfectly. I get no error messages with either old or new reports. The reports work under iReport (3.5.2). I suspect there might be a compatibility issue between swtJasperViewer 1.2.0 and JasperReports 3.5.1. Any input would be appreciated.