Community
Participate
Working Groups
The Xtext project has used Guice with a lot of success to allow customers to replace almost every part of the framework with custom components. Please consider converting BIRT for the next major release to Guice, too. This would reduce unnecessary dependencies between modules, get rid of global variables like BirtReportServiceFactory.service and allow to tweak engine setup, logging and various other aspect of BIRT. For what it's worth, I have create a local fork where I started to do this. It's not a lot of work and migration can be done in several steps, so it's low risk - unless you want to restructure some of the code at the same time.
What do you think BIRT can do with Guice? BIRT uses OSGi extension framework to resolve module depending.
I'm not talking about class loading. BIRT code contains a lot of singletons which make it hard to test, integrate and extend. Just look at the code which calls BirtReportServiceFactory.init() - you need to call this several times from several places in the JEE life cycle to make sure the factory eventually is initialized. I want to get rid of the singletons like BirtReportServiceFactory and all the others. I know that OSGi offers a "Blueprint Service" which does DI and IoC. Maybe this can be used instead of Guice. My concern is that Xtext uses Guice and Xtext is a very successful project. Using the code gives me a feeling that a lot of thought has went into it. When these people chose Guice over OSGi, that's a strong indication for me to wonder why.
I'm not sure the component change makes sense. I only mentioned the singletons in the viewer component but the engine also uses singletons. Similarily, ReportEngine uses new to create a ReportEngineHelper which means that it's impossible to overrode the behavior of that class. With DI, it would be possible to configure these pieces of the BIRT framework and inject them preconfigured instead of adding options to AppContext or the EngineConfig.
OK. Get it. We will discuss about it. Thanks.
