Community
Participate
Working Groups
Build Identifier: We have a custom BIRT 2.6 application that doesn't use the sample web app, but instead creates its own parameter dialogs. We'd like to upgrade to 3.7. However, BIRT 3.7's new deployment model puts all the BIRT libraries in the application server's classpath. This is a problem because our app uses many of the same libraries, but different versions. This wasn't a problem when BIRT used OSGI because they were all loaded in a different classloader. There are around 20 overlapping libraries. I could try to take the latest version of each lib and hope for the best, but that's a very poor solution: even if it appears to work at first glance, there could be subtle bugs. Or bugs that show up as I use more BIRT features. Or bugs that show up when I have to upgrade my platform's libraries later on. Another problem with this approach is that I'd have to repeat the process and in-depth QA every time BIRT releases a new version. It would significantly increase the ongoing cost of using BIRT in our custom web application, and the bottom line is we'd never be able to fully trust it because it would be running on the wrong library versions. I would love a way to invoke BIRT in a separate classloader, whether it be the previous OSGI-based way or something else. Thanks! Reproducible: Always Steps to Reproduce: 1. Put all of BIRT 3.7's libs in our app's classpath 2. Start app 3. See a bunch of errors related to wrong versions of APIs, like missing methods.
Provide Birt OSGI runtime package in 3.7.2 RC1. And OSGI runtime package is displayed in Eclipse Birt download page: http://download.eclipse.org/birt/downloads/build.php?build=M-R1-3.7.2RC1-201201171144
