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 <mansour.alak...@gmail.com> 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 <a...@cohsoft.com.au> 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 <mansour.alak...@gmail.com> 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
<erwan.de-ferrie...@nereide.fr> 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: sa...@cohsoft.com.au

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

Reply via email to