I think BIRT should be moved to Extras. The main reasons being: - we're still not (IMO) giving enough power to the users themselves to create reports - not every company wants to use BIRT and nor should they have to - the engine is large, the integration is lightweight and last time I looked the API was pretty poorly documented
IMO the best thing we could do for reporting in OFBiz is to provide some type of HTTP based data provider interface. Virtually every reporting tool can consume CSV or XML formatted data from web resources and it would allow user's to cut up the data any way they liked via their reporting tool of choice (even something like Excel could be used). We could consider creating some new entities and a UI for controlling what data can be published and to who, possibly even creating a UI that allows dynamic view entities to be constructed and published. Even this idea is possible to deploy as a hot-deploy component so doesn't necessarily need to exist in the framework but it's certainly a much more generic and accessible approach than what we have with BIRT (which it should be noted wasn't chosen for it's features but rather because it was the only one with a permissive license for inclusion). Regards Scott On 26/03/2012, at 8:25 PM, Jacques Le Roux wrote: > Which is one of reasons to have mostly unused things (not only BIRT) out of > OFBiz. > BTW from this POV the POS is not a problem, since it's not a webapp, it runs > only at demand... > > Jacques > > Anne wrote: >> Just for the record, we disable the birt container. I don't like loading >> things I know aren't being used. >> >> Cheers, >> Anne. >> >> On 23 March 2012 22:33, Mansour Al Akeel <[email protected]> wrote: >> >>> in the config for base: >>> >>> base/config/ofbiz-containers.xml: <!-- load the BIRT container --> >>> base/config/ofbiz-containers.xml: <container name="birt-container" >>> class="org.ofbiz.birt.container.BirtContainer"/> >>> >>> >>> This is what loads Birt. Not sure if there's something else needed to load >>> it. >>> Can this be temporary used until OSGI is introduced. OSGI makes it >>> easy to load and unload any component. So (if done properly), no >>> integration in the framework should be done. In this case Birt >>> component should contain the logic to load its self when deployed into >>> OSGI container. So those who needs it can just install it with one >>> command. >>> >>> In the mean while, cleaning the code base will make it easier to look >>> into the messy code in framework, and remove what is not needed. Which >>> will help bringing new things like OSGI to the table. >>> >>> >>> On Thu, Mar 22, 2012 at 7:58 PM, Anne <[email protected]> wrote: >>>> +1 to Mansour's comments. >>>> >>>> I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and >>>> Groovy I currently >>>> >>>>>> 2. can use ofbiz fieldnames and entity names. (not databasenames) >>>>>> 3. can use OFBiz views..... >>>>>> 4. can fully integrate in the ERP application. >>>>>> 5. has many inbuilt output formats. >>>> >>>> (points are from Hans earlier email, though maybe my idea of "fully >>>> integrate" isn't the same as Hans). I presume I can also incorporate the >>>> warehouse entities, and use minilang (Hans' other two points), though I >>>> haven't yet tried either. Maybe it is easier to do these things with Birt, >>>> but I don't have any difficulty with JasperReports. >>>> >>>> More importantly to me, if I decide to drop JasperReports and move to >>>> something else later, it won't be very difficult. >>>> >>>> I am sure Hans integration of Birt would be very useful for those who use >>>> Birt, and I expect they appreciate his effort. If Birt was in Extras, >>>> perhaps some of those people would be more likely to contribute to its >>>> maintenance. >>>> >>>> Cheers, >>>> Anne. >>>> >>>> On 23 March 2012 01:37, Mansour Al Akeel <[email protected]> wrote: >>>> >>>>> I don't know why birt is integrated with Ofbiz. A reporting tools, is >>>>> an add-on to any database driven system, and not essential for the >>>>> over all functionality. Yes all of us need reports, and most of the >>>>> time we use a reporting engine, but why can't it be separated from the >>>>> code base, and used as a separate application ? >>>>> >>>>> From my perspective, the core should contain only components needed to >>>>> bring it up to a functional state. Entity Engine, Service Engine, fall >>>>> under this category. Some may argue that UI should be considered as >>>>> well, and this is valid argument. But when it comes to reporting >>>>> engine, I don't think so. >>>>> >>>>> >>>>> >>>>> On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES >>>>> <[email protected]> wrote: >>>>>> Le 22/03/2012 02:38, Hans Bakker a écrit : >>>>>> >>>>>>> Jacopo, >>>>>>> >>>>>>> you are making here a very negative review of the Birt integration....as >>>>>>> any component sure there is room for improvement however.... >>>>>>> >>>>>>> Some positives you did not even notice? >>>>>>> >>>>>>> 1. can use minilanguage for the retrieval >>>>>>> 2. can use ofbiz fieldnames and entity names. (not databasenames) >>>>>>> 3. can use OFBiz views..... >>>>>>> 4. can fully integrate in the ERP application. >>>>>>> 5. has many inbuilt output formats. >>>>>>> 6. Incorporates the warehouse entities. >>>>>>> >>>>>>> Created/extended the datawarehouse which is essential for ordereporting. >>>>>>> We have very big customers where using order reports directly on the >>>>>>> OFBiz database was not possible. >>>>>>> >>>>>>> This warehouse function is essential for large customers >>>>>>> >>>>>>> I very strongly think about keeping this in the framework. >>>>>>> >>>>>>> BI component I agree, can go.... >>>>>>> >>>>>>> Regards, >>>>>>> Hans >>>>>>> >>>>>>> >>>>>> >>>>>> I'm in two minds about BIRT. It's a fine tool to make reports, but >>>>>> underused >>>>>> in OFBiz. >>>>>> If the concerns Jacopo has about it were resolved, will it be kept in >>>>>> framework ? >>>>>> Also, creating more of those reports (with not available features in >>>>>> FOP), >>>>>> will this go in the right way to keep it there ? >>>>>> >>>>>> >>>>>> -- >>>>>> Erwan de FERRIERES >>>>>> www.nereide.biz >>>>> >>>> >>>> >>>> >>>> -- >>>> Coherent Software Australia Pty Ltd >>>> PO Box 2773 >>>> Cheltenham Vic 3192 >>>> Phone: (03) 9585 6788 >>>> Fax: (03) 9585 1086 >>>> Web: http://www.cohsoft.com.au/ >>>> Email: [email protected] >>>> >>>> Bonsai ERP, the all-inclusive ERP system >>>> http://www.bonsaierp.com.au/
