Are there significant differences between the plugin and the
stand-alone
versions of iReport?
There are no particular
differences in terms of
functionalities. In the future we plan to improve the integration with
Java
projects when iReport is executed as a plugin inside the IDE, allowing
the use
of the project classpath to run a report. The stand-alone version
better serves
non-technical users who are interested only in design reports and not
in writing
code; and developers using other environments and looking for something
lighter
than the whole IDE.Why integrate iReport with the NetBeans IDE?NetBeans provides a set of services and functionalities that we had to write on our own in the previous version of iReport. Moving to NetBeans gave us a lot of features—in a modern implementation and completely maintained by Sun— for free. Such as the visual library for the main designer, the window docking system, the property sheets, the data oriented tree, and much more.We were thus able to concentrate efforts on the core functionalities of our application. A standard platform enables the use of modules provided by third parties to quickly grow the set of functionalities offered out-of-the-box. It is easier for new developers to be involved in the project since all the platform APIs are well-known and documented, thus making the source code of iReport results easy to understand and extend. What features of the NetBeans IDE does the plugin use?iReport makes good use of pretty much all the base NetBeans API. The DB module in particular functions as a way to define the database connections, and the user can use it to design SQL queries and explore the database as well—a handy feature that’s beyond the scope of the application, but that we got for free using the module just to manage the JDBC drivers and connections. As I already mentioned, tight integration with Java projects is on the roadmap.Prior to creating iReport, what was your experience with the NetBeans Platform?My experience was essentially null. I started by reading the book: “Rich Client Programming: Plugging into the NetBeans Platform”, written by Tim Boudreau, Jaroslav Tulach and Geertjan Wielenga.It does not make assumptions about your knowledge of the NetBeans Platform, making it perfect for people approaching platform development for the first time. Using real life samples, it goes through all the main APIs and allows you to start writing code almost immediately. It is not a exhaustive reference of the NetBeans APIs and the Platform (this would require more than a single book) but it gives you the tools to find out the rest. The second great place to get started with plugin development is looking at the code. This may be a bit rude, but there are so many code patterns that when you compare several modules you discover that you are more or less writing the same code. Finally, the NetBeans mailing lists are great sources of knowledge. It’s where you really get the sense that there is a strong and passionate community centered around NetBeans. And finding someone to help solve a problem is pretty easy. Why did you choose to build iReport with the NetBeans Platform?I began to consider moving iReport to the NetBeans Platform after attending JavaOne in 2007. During that occasion, I met Toni Epple who was already working on a designer for JasperReports based on the NetBeans Platform, and that I thought was pretty cool. I was looking for a platform to move iReport onto; iReport was completely written using Swing, so the opportunity to reuse a lot of the existing code for the UI in the new version was great.Are there improvements you'd like to see in the NetBeans Platform?An easy way to dynamically extend the global classpath. Currently, several third parties libraries still rely on the system classpath when they dynamically look for a class (using the Class.forName() method instead of relying on the thread context class loader). In the original version, iReport had a special directory (lib) for this purpose: all the jars in that directory were added to the system classpath at startup. Of course, there are lots of implications to allowing users to add a jar with a global visibility in the NetBeans IDE: this would break all the rules and the efforts to manage classpath visibility of each module, but it would solve a lot of problems at platform level, where the risk of a class conflict is really low.Are there updates to the plugin for NetBeans 6.1?We just fixed a couple of incompatibilities (due to API changes). The good news is that Sun has been really responsive in helping to figure out the problem and reconsidering the particular API change.What is the roadmap for iReport for NetBeans, and what can users
expect?
We still have a lot of work to do, but iReport 0.9.1
represents a very important milestone since it is the first version
that
provides visual support of all the JasperReports 2.0.5 features
(meaning you do
not have to write a single line of jrxml).
The next major steps will be better support for export formats (currently the export of a report in a particular format can be done only using the preview window), full support for internationalization (i18n) and usability improvements (and here the list is very long). We plan to reach all the functionalities offered by the current standard version of iReport in June, at which time the port will be complete and the old version will be no longer be developed in favor of the NetBeans version. (April
2008)
| | ||