PDA

View Full Version : BIRT version



gwessels
11-29-2005, 07:15 AM
Hello Admins,

I'd like to know what Pentaho's policy is regarding the versions' of the modules included in Pentaho releases. BIRT for example has a stable build version out that has more functionality than the release build version even though they're both still version one. I'd imagine that the stable version would require the corresponding runtime in Pentaho in order for the added functionality to work?

Well, actually I tried running a “stable build version??? report in Pentaho and it doesn't work. I suppose it is the 'version=???3??? id=???1???' attributes in the .rptdesign file that make it to fail? The “release build version???'s attribute is only 'version=???2???'.

Would it be open heart surgery for a novice like me to plug the new runtime into Pentaho. I know that if the API has changed then code changes would be required on your (or my) part to get it to work, but if it is only a matter of replacing the runtime it shouldn't be that hard :unsure:?

Thanks,

Gerhard

mbatchelor
11-29-2005, 08:07 AM
Hi Gerhard,

It shouldn't be that difficult at all to replace the runtimes. Here's what you can expect to have to do:


In the solutions system folder is the majority of the used BIRT plugins. It's in this folder that you'd replace each of the plugin folders with the ones from the new build.

In the pentaho.war/WEB-INF/lib folder, you'll find the following .jar files that you'll have to replace:

chart-engine.jar
core.jar
device-extension.jar
device-svg.jar
dte.jar
engine.jar
engine-extension.jar
model.jar
oda.jar
reportitem.jar

Depending upon BIRT's new minimum requirements, you may also need to replace the following jars. These are not BIRT-specific, but instead, they are requirements of BIRT.

common.jar (Eclipse EMF)
common.resources.jar (Eclipse EMF)
ecore.jar (Eclipse EMF)
ecore.resources.jar (Eclipse EMF)
ecore.xmi.jar (Eclipse EMF)
fop.jar (Apache FOP)



Please give us feedback whether or not the new version simply plugs in or not. Bear in mind that the API for launching reports may have changed slightly (or significantly). The new version may require some tweaks in the BIRTReportComponent class which can be found (in the source tree) at org.pentaho.birt.BIRTReportComponent.

Hope this helps,

Marc

Post edited by: mbatchelor, at: 11/29/2005 12:17

adeshazor
11-29-2005, 09:14 AM
Following Marc’s instructions, I’ve upgraded to the latest BIRT stable build; however, I encounter IllegalArgumentExceptions from BIRT classes when running any of the Pentaho BIRT samples. I attached the stack trace. We will tackle the code changes necessary to support the latest version.

http://forums.pentaho.org/archived_att/files/IllegalArgumentException.txt

Post edited by: adeshazor, at: 12/02/2005 11:44

gwessels
11-30-2005, 12:07 AM
I'll be trying the upgrade soon and report back. However I'm not that hopeful that it will work because BIRT have added several new features since the release build. I wouldn't be surprised if the API has changed as well. It would be disappointing however if the API has changed with regards to existing features, i.e. no backward compatibility. The new runtime should recognize the previous file version and process it accordingly. But let me not jump the gun – I will test it first. I'll check the release notes of the stable build for some clues. I hope I am successful.

I've noticed that the stable build includes the much awaited (well I have been waiting for it) dynamic filter support. How will the inclusion of this feature and its related spin-offs like cascading parameters affect Pentaho's dynamic filter solution using the SecureFilterComponent? My first thoughts on this would be for Pentaho to rather adopt the BIRT implementation instead of its own because it would make deploying reports easier in terms of the configuration of the action sequence (that is unless the workbench will make this very easy).

I have a few further thoughts on this:

It would make sense for Pentaho to follow BIRT's (and other modules' for that matter) features closely instead of implementing their own as this would reduce the load on Pentaho of adding features, maintaining them and providing support. Tying together different business intelligence frameworks should remain Pentaho's focus and not filling the gaps of these frameworks. If the framework has a huge omission in its feature set (as the lack of dynamic filters in BIRT was as far as I am concerned) Pentaho could venture to solve it temporarily like they did with the SecureFilterComponent (unless this was a planned feature from the start), but only until the feature has been added to the framework itself. The framework could build significantly on the feature in the future (like cascading parameters) which Pentaho would be pressured to support also with their own solution. But I guess this is what you are doing anyway hey?! :P

Thanks for the great work guys!

Regards,

Gerhard

jdixon
11-30-2005, 10:44 AM
Hi gerhard,

We will try to deploy the latest version of BIRT into Pentaho and see if we can solve the problems.

You can certainly use the dynamic filter feature in BIRT if it meets your need.

We will continue to support and approve our filter component because:

* You can centrally maintain the filters instead of embedding the same query into multiple report files
* You can control when the query is run, once per server, once per user, every time the report is run
* You can use MDX and scripting data sources as well as SQL data sources
* You can apply the filter to dashboard controls, in workflows, etc., as well as reports

I'm not sure if the BIRT report engine ensures that a selected paramter is a valid entry in the list, .

James