Lose Weight Program for OFBiz

[Malin Nicolas]

enthusiasm is the word :) .

The Lose Weight Program is a great lead for future, I understand that
some people (and some customer) are afraid by this change.
So we would tend to rise over the benefits of an organization whereby we
have been working on for some years with Apache OFBiz and justifypassage
of several component extras.

Thanks for the reminding Jacopo to stop the flood and refocus threads.

I looked forward to opening the thread, how to manage migration and how
to manage extrascomponents from Apache OFBiz.
Nicolas

Le 22/03/2012 06:59, Jacopo Cappellato a écrit :

> On Mar 21, 2012, at 8:20 PM, Olivier Heintz wrote:
>
>> not, maybe a directory a the same level as ofbiz in the svn repository, and plug-in manager will be able to download it to hot-deploy (or specialpurpose) and maybe update some file which is needed (ex: add some target in ofbiz build.xml)
>> goals is
>> - easy install process
>> - svn repository and comitters are from Apache-OFBiz
> I find a bit confusing all this push for adding your "plug-in" architecture to OFBiz and to implement your plan to migrate screens to screenlet: I understand the enthusiasm and that these 2 tasks are a priority for you and your group, but please understand that this doesn't mean that it must be a priority for the OFBiz community as well.
> You can propose this (as you did) but please do not flood every thread with these ideas.
> In particular in the "Lose Weight Program" emails we are simply discussing to move or not some of the components to Extras/Attic: let's stay focused on this.
>
> Jacopo

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Jacques Le Roux]

From your remarks it seems then that it introduces dependencies from applications.
This is a part of what we are trying to avoid

Jacques

Hans Bakker wrote:

> 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
>
>
> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>>> L) framework/birt (and related dependencies/reports spread around): move to "Extras"
>>>
>>> M) framework/bi (and related dependencies - ecas/business rules and data - spread around): move to "Extras"
>>>
>> This is an area where Hans and I are in disagreement and we didn't get much feedback from others.
>>
>> So I would like to explain here why I think we should move the Birt component and the Birt reports out of the framework and
>> consider them as optional tools.
>>
>> There are currently 18 reports in the applications implemented with Birt; but they really seem experiments rather than something
>> really usable; to give you some examples:
>>
>> * in most of them there is this code like this:
>>
>> userLogin = null;
>> try {
>>      userLogin = delegator.findByPrimaryKey("UserLogin",UtilMisc.toMap("userLoginId","admin"));
>> } catch(e) {
>>          Debug.logError(e,"");
>> }
>>
>> * all the retrieval logic (scripts) is inlined with layout definition and this is something we try to avoid in all the existing
>> screens
>> * entity list iterators are not properly closed
>> * some of the widget based financial reports have been converted to Birt: their layout is still very simple and comparable to
>> the widget based versions available before Birt; so the conversion to Birt added a dependencies on this component without adding
>> real value (the rptdesign files mix together data preparation scripts and ui definitions and in order to maintain them you have
>> to use the Birt designer); also some of them are now broken: Income Stetements, Balance Sheet etc... This is probably caused by
>> the recent refactoring of JSR-223 but the original widget based PDF are still there and are working fine...    
>> * building a report with this Birt integration still requires a lot of development work (similar to the one required to create a
>> screen); but then the code in the rptdesign is very difficult to maintain without the editor
>>
>> My questions are:
>> * do you really think that this way of integrating rptdesign reports is the answer to fill the gap of a good reporting tool in
>> OFBiz? Are you actually using this integration for your reports?
>> * do we all agree to make this Birt integration the best practice mechanism for all OFBiz reports?
>> * do you really think that we should replace all the existing widget generated reports and FOP reports with rptdesign reports
>> built using the existing Birt integration under the framework?
>>
>> If any of your answers will be "no" then in my opinion it would be much better to:
>> 1) make Birt integration an optional component, downloaded separately
>> 2) move the existing rptdesign reports out of the applications and keep them in the external Birt component
>> 3) at this point users will have the option to use the Birt component or not, but the ootb code will be clean and without
>> dependencies on it; most of all, we will not deliver reports that looks similar (ugly) but they are implemented randomly with
>> Birt or Widgets 4) start evaluating, as a community, what should be the best practices for ootb reports: what is the tool we
>> want, what are the minimal requirements etc... and then work together to get it in place and then migrate all existing reports
>> to it in order to have a consistent system; if the community will not be able to reach a consensus on this, then we should leave
>> the decision about the reporting tool to use to the end user    
>>
>> I think that the Birt integration is a nice optional component, and I see that there may be interested parties, but in its
>> current status it is not something ready for becoming the primary reporting tool for the ootb applications.
>>
>> Jacopo

[hans_bakker]

dependencies from applications to Birt in the framework?
sure because Birt is part of the framework.....

warehouse entities and reports on them belong to the applications, not
to the birt application.

Regards,
Hans

On 03/22/2012 05:11 PM, Jacques Le Roux wrote:

> From your remarks it seems then that it introduces dependencies from
> applications. This is a part of what we are trying to avoid
>
> Jacques
>
> Hans Bakker wrote:
>> 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
>>
>>
>> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>>>> L) framework/birt (and related dependencies/reports spread around):
>>>> move to "Extras"
>>>>
>>>> M) framework/bi (and related dependencies - ecas/business rules and
>>>> data - spread around): move to "Extras"
>>>>
>>> This is an area where Hans and I are in disagreement and we didn't
>>> get much feedback from others.
>>>
>>> So I would like to explain here why I think we should move the Birt
>>> component and the Birt reports out of the framework and
>>> consider them as optional tools.
>>> There are currently 18 reports in the applications implemented with
>>> Birt; but they really seem experiments rather than something
>>> really usable; to give you some examples:
>>> * in most of them there is this code like this:
>>>
>>> userLogin = null;
>>> try {
>>>      userLogin =
>>> delegator.findByPrimaryKey("UserLogin",UtilMisc.toMap("userLoginId","admin"));
>>> } catch(e) {
>>>          Debug.logError(e,"");
>>> }
>>>
>>> * all the retrieval logic (scripts) is inlined with layout
>>> definition and this is something we try to avoid in all the existing
>>> screens * entity list iterators are not properly closed
>>> * some of the widget based financial reports have been converted to
>>> Birt: their layout is still very simple and comparable to
>>> the widget based versions available before Birt; so the conversion
>>> to Birt added a dependencies on this component without adding
>>> real value (the rptdesign files mix together data preparation
>>> scripts and ui definitions and in order to maintain them you have
>>> to use the Birt designer); also some of them are now broken: Income
>>> Stetements, Balance Sheet etc... This is probably caused by
>>> the recent refactoring of JSR-223 but the original widget based PDF
>>> are still there and are working fine...    * building a report with
>>> this Birt integration still requires a lot of development work
>>> (similar to the one required to create a
>>> screen); but then the code in the rptdesign is very difficult to
>>> maintain without the editor
>>> My questions are:
>>> * do you really think that this way of integrating rptdesign reports
>>> is the answer to fill the gap of a good reporting tool in
>>> OFBiz? Are you actually using this integration for your reports? *
>>> do we all agree to make this Birt integration the best practice
>>> mechanism for all OFBiz reports?
>>> * do you really think that we should replace all the existing widget
>>> generated reports and FOP reports with rptdesign reports
>>> built using the existing Birt integration under the framework?
>>> If any of your answers will be "no" then in my opinion it would be
>>> much better to:
>>> 1) make Birt integration an optional component, downloaded separately
>>> 2) move the existing rptdesign reports out of the applications and
>>> keep them in the external Birt component
>>> 3) at this point users will have the option to use the Birt
>>> component or not, but the ootb code will be clean and without
>>> dependencies on it; most of all, we will not deliver reports that
>>> looks similar (ugly) but they are implemented randomly with
>>> Birt or Widgets 4) start evaluating, as a community, what should be
>>> the best practices for ootb reports: what is the tool we
>>> want, what are the minimal requirements etc... and then work
>>> together to get it in place and then migrate all existing reports
>>> to it in order to have a consistent system; if the community will
>>> not be able to reach a consensus on this, then we should leave
>>> the decision about the reporting tool to use to the end user
>>> I think that the Birt integration is a nice optional component, and
>>> I see that there may be interested parties, but in its
>>> current status it is not something ready for becoming the primary
>>> reporting tool for the ootb applications.
>>> Jacopo

[Jacques Le Roux]

I mean the framework should know nothing about applications

>>> 6. Incorporates the warehouse entities.


Jacques

From: "Hans Bakker" <[hidden email]>

> dependencies from applications to Birt in the framework?
> sure because Birt is part of the framework.....
>
> warehouse entities and reports on them belong to the applications, not
> to the birt application.
>
> Regards,
> Hans
>
> On 03/22/2012 05:11 PM, Jacques Le Roux wrote:
>> From your remarks it seems then that it introduces dependencies from
>> applications. This is a part of what we are trying to avoid
>>
>> Jacques
>>
>> Hans Bakker wrote:
>>> 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
>>>
>>>
>>> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>>>>> L) framework/birt (and related dependencies/reports spread around):
>>>>> move to "Extras"
>>>>>
>>>>> M) framework/bi (and related dependencies - ecas/business rules and
>>>>> data - spread around): move to "Extras"
>>>>>
>>>> This is an area where Hans and I are in disagreement and we didn't
>>>> get much feedback from others.
>>>>
>>>> So I would like to explain here why I think we should move the Birt
>>>> component and the Birt reports out of the framework and
>>>> consider them as optional tools.
>>>> There are currently 18 reports in the applications implemented with
>>>> Birt; but they really seem experiments rather than something
>>>> really usable; to give you some examples:
>>>> * in most of them there is this code like this:
>>>>
>>>> userLogin = null;
>>>> try {
>>>>      userLogin =
>>>> delegator.findByPrimaryKey("UserLogin",UtilMisc.toMap("userLoginId","admin"));
>>>> } catch(e) {
>>>>          Debug.logError(e,"");
>>>> }
>>>>
>>>> * all the retrieval logic (scripts) is inlined with layout
>>>> definition and this is something we try to avoid in all the existing
>>>> screens * entity list iterators are not properly closed
>>>> * some of the widget based financial reports have been converted to
>>>> Birt: their layout is still very simple and comparable to
>>>> the widget based versions available before Birt; so the conversion
>>>> to Birt added a dependencies on this component without adding
>>>> real value (the rptdesign files mix together data preparation
>>>> scripts and ui definitions and in order to maintain them you have
>>>> to use the Birt designer); also some of them are now broken: Income
>>>> Stetements, Balance Sheet etc... This is probably caused by
>>>> the recent refactoring of JSR-223 but the original widget based PDF
>>>> are still there and are working fine...    * building a report with
>>>> this Birt integration still requires a lot of development work
>>>> (similar to the one required to create a
>>>> screen); but then the code in the rptdesign is very difficult to
>>>> maintain without the editor
>>>> My questions are:
>>>> * do you really think that this way of integrating rptdesign reports
>>>> is the answer to fill the gap of a good reporting tool in
>>>> OFBiz? Are you actually using this integration for your reports? *
>>>> do we all agree to make this Birt integration the best practice
>>>> mechanism for all OFBiz reports?
>>>> * do you really think that we should replace all the existing widget
>>>> generated reports and FOP reports with rptdesign reports
>>>> built using the existing Birt integration under the framework?
>>>> If any of your answers will be "no" then in my opinion it would be
>>>> much better to:
>>>> 1) make Birt integration an optional component, downloaded separately
>>>> 2) move the existing rptdesign reports out of the applications and
>>>> keep them in the external Birt component
>>>> 3) at this point users will have the option to use the Birt
>>>> component or not, but the ootb code will be clean and without
>>>> dependencies on it; most of all, we will not deliver reports that
>>>> looks similar (ugly) but they are implemented randomly with
>>>> Birt or Widgets 4) start evaluating, as a community, what should be
>>>> the best practices for ootb reports: what is the tool we
>>>> want, what are the minimal requirements etc... and then work
>>>> together to get it in place and then migrate all existing reports
>>>> to it in order to have a consistent system; if the community will
>>>> not be able to reach a consensus on this, then we should leave
>>>> the decision about the reporting tool to use to the end user
>>>> I think that the Birt integration is a nice optional component, and
>>>> I see that there may be interested parties, but in its
>>>> current status it is not something ready for becoming the primary
>>>> reporting tool for the ootb applications.
>>>> Jacopo
>

[hans_bakker]

sure...but then i do not understand your comment...where do i indicate
there is a dependency from the framework on an application? Warehouse
entities are stored in the application?

On 03/22/2012 06:14 PM, Jacques Le Roux wrote:

> I mean the framework should know nothing about applications
>
>>>> 6. Incorporates the warehouse entities.
>
>
> Jacques
>
> From: "Hans Bakker" <[hidden email]>
>> dependencies from applications to Birt in the framework?
>> sure because Birt is part of the framework.....
>>
>> warehouse entities and reports on them belong to the applications,
>> not to the birt application.
>>
>> Regards,
>> Hans
>>
>> On 03/22/2012 05:11 PM, Jacques Le Roux wrote:
>>> From your remarks it seems then that it introduces dependencies from
>>> applications. This is a part of what we are trying to avoid
>>>
>>> Jacques
>>>
>>> Hans Bakker wrote:
>>>> 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
>>>>
>>>>
>>>> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>>>>>> L) framework/birt (and related dependencies/reports spread
>>>>>> around): move to "Extras"
>>>>>>
>>>>>> M) framework/bi (and related dependencies - ecas/business rules
>>>>>> and data - spread around): move to "Extras"
>>>>>>
>>>>> This is an area where Hans and I are in disagreement and we didn't
>>>>> get much feedback from others.
>>>>>
>>>>> So I would like to explain here why I think we should move the
>>>>> Birt component and the Birt reports out of the framework and
>>>>> consider them as optional tools.
>>>>> There are currently 18 reports in the applications implemented
>>>>> with Birt; but they really seem experiments rather than something
>>>>> really usable; to give you some examples:
>>>>> * in most of them there is this code like this:
>>>>>
>>>>> userLogin = null;
>>>>> try {
>>>>>      userLogin =
>>>>> delegator.findByPrimaryKey("UserLogin",UtilMisc.toMap("userLoginId","admin"));
>>>>> } catch(e) {
>>>>>          Debug.logError(e,"");
>>>>> }
>>>>>
>>>>> * all the retrieval logic (scripts) is inlined with layout
>>>>> definition and this is something we try to avoid in all the existing
>>>>> screens * entity list iterators are not properly closed
>>>>> * some of the widget based financial reports have been converted
>>>>> to Birt: their layout is still very simple and comparable to
>>>>> the widget based versions available before Birt; so the conversion
>>>>> to Birt added a dependencies on this component without adding
>>>>> real value (the rptdesign files mix together data preparation
>>>>> scripts and ui definitions and in order to maintain them you have
>>>>> to use the Birt designer); also some of them are now broken:
>>>>> Income Stetements, Balance Sheet etc... This is probably caused by
>>>>> the recent refactoring of JSR-223 but the original widget based
>>>>> PDF are still there and are working fine...    * building a report
>>>>> with this Birt integration still requires a lot of development
>>>>> work (similar to the one required to create a
>>>>> screen); but then the code in the rptdesign is very difficult to
>>>>> maintain without the editor
>>>>> My questions are:
>>>>> * do you really think that this way of integrating rptdesign
>>>>> reports is the answer to fill the gap of a good reporting tool in
>>>>> OFBiz? Are you actually using this integration for your reports? *
>>>>> do we all agree to make this Birt integration the best practice
>>>>> mechanism for all OFBiz reports?
>>>>> * do you really think that we should replace all the existing
>>>>> widget generated reports and FOP reports with rptdesign reports
>>>>> built using the existing Birt integration under the framework?
>>>>> If any of your answers will be "no" then in my opinion it would be
>>>>> much better to:
>>>>> 1) make Birt integration an optional component, downloaded separately
>>>>> 2) move the existing rptdesign reports out of the applications and
>>>>> keep them in the external Birt component
>>>>> 3) at this point users will have the option to use the Birt
>>>>> component or not, but the ootb code will be clean and without
>>>>> dependencies on it; most of all, we will not deliver reports that
>>>>> looks similar (ugly) but they are implemented randomly with
>>>>> Birt or Widgets 4) start evaluating, as a community, what should
>>>>> be the best practices for ootb reports: what is the tool we
>>>>> want, what are the minimal requirements etc... and then work
>>>>> together to get it in place and then migrate all existing reports
>>>>> to it in order to have a consistent system; if the community will
>>>>> not be able to reach a consensus on this, then we should leave
>>>>> the decision about the reporting tool to use to the end user
>>>>> I think that the Birt integration is a nice optional component,
>>>>> and I see that there may be interested parties, but in its
>>>>> current status it is not something ready for becoming the primary
>>>>> reporting tool for the ootb applications.
>>>>> Jacopo
>>

[Erwan de FERRIERES]

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

[Jacopo Cappellato-4]

On Mar 22, 2012, at 12:43 PM, Erwan de FERRIERES 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.

Please note that all the above points are covered also by screens/FOP; and the code in screens/FOP is cleaner and implements the MVC pattern as all the other screens.
You didn't mention the only one reason that really makes meaningful to consider this Birt integration: after you have manually implemented (in the traditional way) controller entries, screens to run the reports and the data preparation code (that needs to be inlined in the Birt report definition) you can use the Birt designer to implement the ui.
This is in my opinion a nice to have for an optional component but not enough to make it the default reporting engine for OFBiz.

>>
>> 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

These ones are not part of the Birt integration but are instead part of the BI framework that I originally designed (and you have expanded): in fact I still see a big potential for this tool, that it is for its nature optional and external to OFBiz (ideally it should run in a separate db) and I really hope to see it more exposed tomore contributors in the future if delivered as an optional application.

>>
>> 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 ?

In its current status I don't see how this could happen; it was not a good move that some of the ootb reports have been converted to Birt because now we have another technology for reporting that it is not enough to become the primary tool; the reports generated using this tool in its current form are simply not good enough to stay; if we will ever want to deliver with the framework an official tool for reporting then its requirements/features should be carefully evaluated before taking a decision

> Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ?

I don't think that adding more Birt reports to OFBiz to make the OFBiz applications more dependent on this imperfect Birt integration would be the right way to go. Instead we should rather gather all the requirements, design/select the proper tool (Birt of what else) and then integrate it properly and finally convert all the application reports to it. But even if we will reach that point I would see some potential to treat it as an optional/separated tool (but this can be discussed).
In summary my opinion is: for now *this* Birt integration should go to Extras and improved there; interested users will get it from there (together with the reports); if the community thinks we should have a default reporting tool packaged in OFBiz then we will start the architectural/requirement design phase (at that point we could even bring back again some of the existing Birt code, if we think it is the right way to go).

Jacopo

>
>
> --
> Erwan de FERRIERES
> www.nereide.biz

[Mansour]

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
<[hidden email]> 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

[Anne Jessel]

+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 <[hidden email]> 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
> <[hidden email]> 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: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

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

[Mansour]

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 <[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> 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: [phone]
> Fax: [phone]
> Web: http://www.cohsoft.com.au/
> Email: [hidden email]
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/

[princesewani]

+1 to what Anne said, even I used to think that special-purpose is all the extra stuff accept e-commerce which I wondered why it lies there,
pretty much everything is captured in applications if we consider a complete ERP accept assetmaint and and projectmgr, these two should also have been a part of applications,
and if not atleast assetmaint, as any organization has assets and its accounted. Projectmgr could stay in special-purpose.


Regards
Prince



________________________________
 From: Anne <[hidden email]>
To: [hidden email]
Sent: Thursday, March 22, 2012 7:16 AM
Subject: Re: Lose Weight Program for OFBiz - what should go to specialpurpose
 
If we can agree on exactly what specialpurpose will be for in future, we
might find it easy to decide what to move.

My original thought was that specialpurpose is for the "extras" that most
people won't want. But in future Apache Extras will be doing that. So
should we remove specialpurpose totally? Everything in it goes either to
Extras or to Applications?

I have not decided whether I like that idea. Only thing I am sure of is
that ecommerce should stay somewhere in core, but it looks like everyone
else agrees on that.

Cheers,
Anne.

On 22 March 2012 07:06, Mansour Al Akeel <[hidden email]> wrote:

> Thank you Jacques. XUL is the mozilla UI thing.
> I didn't use any of the framework mentioned her :)
>
>
> On Wed, Mar 21, 2012 at 2:24 PM, Jacques Le Roux
> <[hidden email]> wrote:
> > From: "Mansour Al Akeel" <[hidden email]>
> >>
> >> Anil,
> >>
> >> I did not mean that putting a component under "specialpurposes" will
> >> make it used more by developers.
> >> I meant because it will be used more than other component, let's not
> move
> >> it.
> >> From Jacopo's first email about the Lose Weight :
> >>
> >> Legenda for what I propose for each piece of code:
> >> * Attic: remove from code base and document the removal for future
> >> reference in this page
> >> * Extras: identify a person interested in maintaining the code as a
> >> separate project hosted as an Apache Extra project (not officially
> >> under the ASF); add a link to it from the page that will contain
> >> "OFBiz Extras"
> >>
> >> He didn't mention anything about what type of applications should
> >> go/remain under "specialpurposes".
> >> Since (I think), pos is used more than what went into Exta or Attic, I
> >> suggested keeping it where it's.
> >> The question is, will POS be maintained by ofbiz community or another
> >> party ? If it's will be separated from ofbiz, what about XUL
> >> integration code?
> >
> >
> > It's not XUL but XUI (which is a dead project, replaced by Aria which now
> > "smells"* almost as much)
> > http://xui.sourceforge.net/index.html
> > http://www.formaria.org/
> > This does not prevent the POS to work well...
> >
> > Jacques
> > PS: *"smells" like Frank Zappa said about Jazz: "Jazz isn't dead. It just
> > smells funny."
> > http://www.goodreads.com/quotes/show/3092
> > Jazz has much evolved since...Not Aria...
> >
> >
> >> should it remain part of  the core ofbiz (framework), or moved to the
> >> component that needs it, and becomes the responsibility of the "POS"
> >> maintainer ?
> >>
> >>
> >> With regard to changing the License, I think it's possible on any part
> >> of Ofbiz and not only components under Extra.
> >> In all cases, users who uses POS more than I do, can give better
> >> suggestion.
> >>
> >>
> >>
> >> On Wed, Mar 21, 2012 at 11:16 AM, Anil Patel <
> [hidden email]>
> >> wrote:
> >>>>
> >>>>
> >>>> Jacques,
> >>>> I don't use pos, but I think it's good idea to keep it where it's. I
> >>>> think it's more likely, it will be used more than what goes in Extra.
> >>>> It fits "specialpurpose".
> >>>>
> >>>
> >>> Why do you think a component will be used more if its in specialpurpose
> >>> section, instead of Extras.
> >>>
> >>> Personally think it opposite, If a business is interested in using POS,
> >>> they will find be able to find it from Extras as well.
> >>> Like any other Ofbiz application, The Users of POS application will
> will
> >>> respond by saying "UX sucks" :). At that point Company
> >>> who deployed the POS will be motivated to improve it. If POS is in
> Extras
> >>> its will be much easy for new developer to become
> >>> active committer.
> >>>
> >>> In some cases, contributor may want to change License on a components.
> >>> Doing such thing will be possible for Ofbiz Extras.
> >>>
> >>> One of the reasons (I am sure there were many) why OpenTaps was started
> >>> is License.
> >>>
> >>> I will personally like to have more freedom around UI toolset. Ofbiz
> >>> Extras will make it possible. And if application is well
> >>> accepted by users then it will get popular and community will grow.
> >>>
> >>> Regards
> >>> Anil Patel
> >>>
> >>>>
> >>>>
> >>>> On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel
> >>>> <[hidden email]> wrote:
> >>>>>
> >>>>> People are really worried on the idea of moving certain components
> from
> >>>>> Ofbiz trunk to Ofbiz Extras. Why is it so?
> >>>>>
> >>>>> Moving a component from Ofbiz trunk to Ofbiz Extras does not mean
> that
> >>>>> the component is not good and so we are throwing it out.
> >>>>> Instead idea is to allow components to grow by giving them little
> more
> >>>>> freedom.
> >>>>>
> >>>>> Like Jacopo mentioned in one of his responses, Projects from Ofbiz
> >>>>> Extras can still post updates on Ofbiz lists.
> >>>>>
> >>>>> Finally if a Project in Extras is useful for business, people will
> keep
> >>>>> improving it and community will grow.
> >>>>>
> >>>>> Thanks and Regards
> >>>>> Anil Patel
> >>>>> HotWax Media Inc
> >>>>>
> >>>>> On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote:
> >>>>>
> >>>>>> They are more generic sure, I wonder for the pos...
> >>>>>>
> >>>>>> Jacques
> >>>>>>
> >>>>>> From: "Mansour Al Akeel" <[hidden email]>
> >>>>>>>
> >>>>>>> Jacques,
> >>>>>>> Yes. You are right. I meant projectmgr. :)
> >>>>>>> I believe assetmaint and projectmgr are used more than others and
> >>>>>>> good
> >>>>>>> to keep them where they are.
> >>>>>>> Thank you.
> >>>>>>> On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux
> >>>>>>> <[hidden email]> wrote:
> >>>>>>>>
> >>>>>>>> partymgr is in application will not move, you meant ProjectMgr
> >>>>>>>> right?
> >>>>>>>>
> >>>>>>>> Jacques
> >>>>>>>>
> >>>>>>>> From: "Mansour Al Akeel" <[hidden email]>
> >>>>>>>>
> >>>>>>>>> I would recommend keeping partymgr and assetmaint.
> >>>>>>>>> I am not sure if accounting depends on assetmain.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits
> >>>>>>>>> <[hidden email]>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> + 1 on move of majority of apps in specialpurpose to 'Extras',
> >>>>>>>>>> excluding
> >>>>>>>>>> projectmgr as it displays how to use OFBiz in a different
> industry
> >>>>>>>>>> than
> >>>>>>>>>> ecommerce/webshop. Is it not so that OFBiz is versatile.
> >>>>>>>>>> ProjectMgr does
> >>>>>>>>>> deliver some of that versatility.
> >>>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>>
> >>>>>>>>>> Pierre
> >>>>>>>>>>
> >>>>>>>>>> Op 20 maart 2012 12:47 schreef Jacopo Cappellato <
> >>>>>>>>>> [hidden email]> het volgende:
> >>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> H) specialpurpose/*: move several (if not all, apart
> ecommerce)
> >>>>>>>>>>>> of the
> >>>>>>>>>>>
> >>>>>>>>>>> components to "Extras" (if there are persons interested to
> become
> >>>>>>>>>>> committers/maintainers) or to "Attic"
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> There seems to be a general agreement to slim down the number
> of
> >>>>>>>>>>> applications in this group and move them to Extras (see
> >>>>>>>>>>> exceptions
> >>>>>>>>>>> below).
> >>>>>>>>>>> I am summarizing here some notes but we should actually use
> this
> >>>>>>>>>>> thread
> >>>>>>>>>>> to
> >>>>>>>>>>> continue the discussion about what should go to specialpurpose
> in
> >>>>>>>>>>> general
> >>>>>>>>>>> rather than focusing on the decision about removal of specific
> >>>>>>>>>>> applications; we can then start a separate thread for each
> >>>>>>>>>>> component.
> >>>>>>>>>>>
> >>>>>>>>>>> Adrian would like to keep one or two components to demonstrate
> >>>>>>>>>>> the
> >>>>>>>>>>> concept
> >>>>>>>>>>> of reusing artifacts to create custom applications (Jacopo: can
> >>>>>>>>>>> we use
> >>>>>>>>>>> the
> >>>>>>>>>>> "exampleext" component for this?)
> >>>>>>>>>>> Hans would like to keep the ones that he considers feature
> >>>>>>>>>>> complete like
> >>>>>>>>>>> asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr
> and
> >>>>>>>>>>> scrum.
> >>>>>>>>>>> Jacopo: in my opinion even in the above list provided by Hans
> >>>>>>>>>>> there are
> >>>>>>>>>>> applications that are barely examples (cmssite) or are very
> >>>>>>>>>>> specific
> >>>>>>>>>>> implementation of very specific requirements (difficult to be
> >>>>>>>>>>> used if
> >>>>>>>>>>> your
> >>>>>>>>>>> company doesn't have exactly these requirements): projectmgr
> and
> >>>>>>>>>>> scrum;
> >>>>>>>>>>> some of these components also extends (adding special purpose
> >>>>>>>>>>> fields)
> >>>>>>>>>>> the
> >>>>>>>>>>> generic data model and this happens even if the user is not
> >>>>>>>>>>> interested
> >>>>>>>>>>> in
> >>>>>>>>>>> evaluating the specialpurpose component. I also don't think
> that
> >>>>>>>>>>> some of
> >>>>>>>>>>> the components meet minimum quality requirements to be
> >>>>>>>>>>> distributed with
> >>>>>>>>>>> OFBiz: for example the scrum component uses a mechanism that is
> >>>>>>>>>>> unique
> >>>>>>>>>>> to
> >>>>>>>>>>> demo its features (i.e. published a demo webapp with online
> >>>>>>>>>>> instructions
> >>>>>>>>>>> for demo data) that is not used by other applications (and this
> >>>>>>>>>>> makes
> >>>>>>>>>>> the
> >>>>>>>>>>> suite of applications inconsistent); also, the component refers
> >>>>>>>>>>> to
> >>>>>>>>>>> resources that are owned by Hans' company. All in all, they
> seem
> >>>>>>>>>>> very
> >>>>>>>>>>> specific piece of codes that should better live as optional
> >>>>>>>>>>> plugins
> >>>>>>>>>>> downloaded separately. So in my opinion the "concept" of
> >>>>>>>>>>> specialpurpose
> >>>>>>>>>>> application is in general better suited for Apache Extras
> rather
> >>>>>>>>>>> than
> >>>>>>>>>>> for
> >>>>>>>>>>> the OFBiz svn and releases.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>
> >
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

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

[princesewani]

Well pretty much all that we think is an additional integration to the core concept of the application,
like LDAP,Shark, Workfolw, crowd,  all that that is already there seems pretty much thoughtful already.

Regards
Prince



________________________________
 From: Mansour Al Akeel <[hidden email]>
To: [hidden email]
Sent: Thursday, March 22, 2012 1:36 AM
Subject: Re: Lose Weight Program for OFBiz - what should go to specialpurpose
 
Thank you Jacques. XUL is the mozilla UI thing.
I didn't use any of the framework mentioned her :)


On Wed, Mar 21, 2012 at 2:24 PM, Jacques Le Roux
<[hidden email]> wrote:

> From: "Mansour Al Akeel" <[hidden email]>
>>
>> Anil,
>>
>> I did not mean that putting a component under "specialpurposes" will
>> make it used more by developers.
>> I meant because it will be used more than other component, let's not move
>> it.
>> From Jacopo's first email about the Lose Weight :
>>
>> Legenda for what I propose for each piece of code:
>> * Attic: remove from code base and document the removal for future
>> reference in this page
>> * Extras: identify a person interested in maintaining the code as a
>> separate project hosted as an Apache Extra project (not officially
>> under the ASF); add a link to it from the page that will contain
>> "OFBiz Extras"
>>
>> He didn't mention anything about what type of applications should
>> go/remain under "specialpurposes".
>> Since (I think), pos is used more than what went into Exta or Attic, I
>> suggested keeping it where it's.
>> The question is, will POS be maintained by ofbiz community or another
>> party ? If it's will be separated from ofbiz, what about XUL
>> integration code?
>
>
> It's not XUL but XUI (which is a dead project, replaced by Aria which now
> "smells"* almost as much)
> http://xui.sourceforge.net/index.html
> http://www.formaria.org/
> This does not prevent the POS to work well...
>
> Jacques
> PS: *"smells" like Frank Zappa said about Jazz: "Jazz isn't dead. It just
> smells funny."
> http://www.goodreads.com/quotes/show/3092
> Jazz has much evolved since...Not Aria...
>
>
>> should it remain part of  the core ofbiz (framework), or moved to the
>> component that needs it, and becomes the responsibility of the "POS"
>> maintainer ?
>>
>>
>> With regard to changing the License, I think it's possible on any part
>> of Ofbiz and not only components under Extra.
>> In all cases, users who uses POS more than I do, can give better
>> suggestion.
>>
>>
>>
>> On Wed, Mar 21, 2012 at 11:16 AM, Anil Patel <[hidden email]>
>> wrote:
>>>>
>>>>
>>>> Jacques,
>>>> I don't use pos, but I think it's good idea to keep it where it's. I
>>>> think it's more likely, it will be used more than what goes in Extra.
>>>> It fits "specialpurpose".
>>>>
>>>
>>> Why do you think a component will be used more if its in specialpurpose
>>> section, instead of Extras.
>>>
>>> Personally think it opposite, If a business is interested in using POS,
>>> they will find be able to find it from Extras as well.
>>> Like any other Ofbiz application, The Users of POS application will will
>>> respond by saying "UX sucks" :). At that point Company
>>> who deployed the POS will be motivated to improve it. If POS is in Extras
>>> its will be much easy for new developer to become
>>> active committer.
>>>
>>> In some cases, contributor may want to change License on a components.
>>> Doing such thing will be possible for Ofbiz Extras.
>>>
>>> One of the reasons (I am sure there were many) why OpenTaps was started
>>> is License.
>>>
>>> I will personally like to have more freedom around UI toolset. Ofbiz
>>> Extras will make it possible. And if application is well
>>> accepted by users then it will get popular and community will grow.
>>>
>>> Regards
>>> Anil Patel
>>>
>>>>
>>>>
>>>> On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel
>>>> <[hidden email]> wrote:
>>>>>
>>>>> People are really worried on the idea of moving certain components from
>>>>> Ofbiz trunk to Ofbiz Extras. Why is it so?
>>>>>
>>>>> Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that
>>>>> the component is not good and so we are throwing it out.
>>>>> Instead idea is to allow components to grow by giving them little more
>>>>> freedom.
>>>>>
>>>>> Like Jacopo mentioned in one of his responses, Projects from Ofbiz
>>>>> Extras can still post updates on Ofbiz lists.
>>>>>
>>>>> Finally if a Project in Extras is useful for business, people will keep
>>>>> improving it and community will grow.
>>>>>
>>>>> Thanks and Regards
>>>>> Anil Patel
>>>>> HotWax Media Inc
>>>>>
>>>>> On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote:
>>>>>
>>>>>> They are more generic sure, I wonder for the pos...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Mansour Al Akeel" <[hidden email]>
>>>>>>>
>>>>>>> Jacques,
>>>>>>> Yes. You are right. I meant projectmgr. :)
>>>>>>> I believe assetmaint and projectmgr are used more than others and
>>>>>>> good
>>>>>>> to keep them where they are.
>>>>>>> Thank you.
>>>>>>> On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux
>>>>>>> <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> partymgr is in application will not move, you meant ProjectMgr
>>>>>>>> right?
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> From: "Mansour Al Akeel" <[hidden email]>
>>>>>>>>
>>>>>>>>> I would recommend keeping partymgr and assetmaint.
>>>>>>>>> I am not sure if accounting depends on assetmain.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits
>>>>>>>>> <[hidden email]>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> + 1 on move of majority of apps in specialpurpose to 'Extras',
>>>>>>>>>> excluding
>>>>>>>>>> projectmgr as it displays how to use OFBiz in a different industry
>>>>>>>>>> than
>>>>>>>>>> ecommerce/webshop. Is it not so that OFBiz is versatile.
>>>>>>>>>> ProjectMgr does
>>>>>>>>>> deliver some of that versatility.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Pierre
>>>>>>>>>>
>>>>>>>>>> Op 20 maart 2012 12:47 schreef Jacopo Cappellato <
>>>>>>>>>> [hidden email]> het volgende:
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> H) specialpurpose/*: move several (if not all, apart ecommerce)
>>>>>>>>>>>> of the
>>>>>>>>>>>
>>>>>>>>>>> components to "Extras" (if there are persons interested to become
>>>>>>>>>>> committers/maintainers) or to "Attic"
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> There seems to be a general agreement to slim down the number of
>>>>>>>>>>> applications in this group and move them to Extras (see
>>>>>>>>>>> exceptions
>>>>>>>>>>> below).
>>>>>>>>>>> I am summarizing here some notes but we should actually use this
>>>>>>>>>>> thread
>>>>>>>>>>> to
>>>>>>>>>>> continue the discussion about what should go to specialpurpose in
>>>>>>>>>>> general
>>>>>>>>>>> rather than focusing on the decision about removal of specific
>>>>>>>>>>> applications; we can then start a separate thread for each
>>>>>>>>>>> component.
>>>>>>>>>>>
>>>>>>>>>>> Adrian would like to keep one or two components to demonstrate
>>>>>>>>>>> the
>>>>>>>>>>> concept
>>>>>>>>>>> of reusing artifacts to create custom applications (Jacopo: can
>>>>>>>>>>> we use
>>>>>>>>>>> the
>>>>>>>>>>> "exampleext" component for this?)
>>>>>>>>>>> Hans would like to keep the ones that he considers feature
>>>>>>>>>>> complete like
>>>>>>>>>>> asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and
>>>>>>>>>>> scrum.
>>>>>>>>>>> Jacopo: in my opinion even in the above list provided by Hans
>>>>>>>>>>> there are
>>>>>>>>>>> applications that are barely examples (cmssite) or are very
>>>>>>>>>>> specific
>>>>>>>>>>> implementation of very specific requirements (difficult to be
>>>>>>>>>>> used if
>>>>>>>>>>> your
>>>>>>>>>>> company doesn't have exactly these requirements): projectmgr and
>>>>>>>>>>> scrum;
>>>>>>>>>>> some of these components also extends (adding special purpose
>>>>>>>>>>> fields)
>>>>>>>>>>> the
>>>>>>>>>>> generic data model and this happens even if the user is not
>>>>>>>>>>> interested
>>>>>>>>>>> in
>>>>>>>>>>> evaluating the specialpurpose component. I also don't think that
>>>>>>>>>>> some of
>>>>>>>>>>> the components meet minimum quality requirements to be
>>>>>>>>>>> distributed with
>>>>>>>>>>> OFBiz: for example the scrum component uses a mechanism that is
>>>>>>>>>>> unique
>>>>>>>>>>> to
>>>>>>>>>>> demo its features (i.e. published a demo webapp with online
>>>>>>>>>>> instructions
>>>>>>>>>>> for demo data) that is not used by other applications (and this
>>>>>>>>>>> makes
>>>>>>>>>>> the
>>>>>>>>>>> suite of applications inconsistent); also, the component refers
>>>>>>>>>>> to
>>>>>>>>>>> resources that are owned by Hans' company. All in all, they seem
>>>>>>>>>>> very
>>>>>>>>>>> specific piece of codes that should better live as optional
>>>>>>>>>>> plugins
>>>>>>>>>>> downloaded separately. So in my opinion the "concept" of
>>>>>>>>>>> specialpurpose
>>>>>>>>>>> application is in general better suited for Apache Extras rather
>>>>>>>>>>> than
>>>>>>>>>>> for
>>>>>>>>>>> the OFBiz svn and releases.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>

[Olivier.heintz]

Le 21/03/2012 21:56, Jacques Le Roux a écrit :

> From: "Olivier Heintz" <[hidden email]>
>> Le 21/03/2012 19:02, Jacques Le Roux a écrit :
>>> From: "Olivier Heintz" <[hidden email]>
>>>> Le 20/03/2012 15:58, Jacques Le Roux a écrit :
>>>>> From: "Jacopo Cappellato" <[hidden email]>
>>>>>>> A) move framework/guiapp out of the framework; after all these
>>>>>>> years no code made advantage of it being part of the framework
>>>>>>> and it is only used by the specialpurpose/pos component (which
>>>>>>> was the component for which it was built for); so guiapp can go
>>>>>>> in the pos component
>>>>>>>
>>>>>>> B) specialpurpose/pos: move to "Extras"
>>>>>>>
>>>>>>
>>>>>> No one objected so far; Jacques offered his help for #A.
>>>>>> Should we focus on #A for now (it is an actionable item) and then
>>>>>> discuss #B also based on the outcome of similar discussions
>>>>>> for other specialpurpose components?
>>>>>
>>>>> Yes, I know there are POS users out there. So I now wonder if we
>>>>> should not wait before moving it out of specialpurpose. When you
>>>>> think about it, it's the twin of eCommerce. With a bit more
>>>>> involvment though, mostly because of its relation with Entity Sync
>>>>> (maintenance) which is actually part of the framework (entityext
>>>>> component).
>>>> IMO, pos is one of the perfect example which should go in a
>>>> Apache-OFbiz-SubProject not out of Apache-Ofbiz,
>>>> of course +1 to becoming a plug-in but one of the Apache-OFBiz
>>>> official plug-in
>>>
>>> What are exactly Apache-OFbiz-SubProject  and Apache-OFBiz official
>>> plug-in in your mind?
>>> specialpurpose components?
>> not, maybe a directory a the same level as ofbiz in the svn
>> repository, and plug-in manager will be able to download it to
>> hot-deploy (or specialpurpose) and maybe update some file which is
>> needed (ex: add some target in ofbiz build.xml)
>> goals is
>> - easy install process
>> - svn repository and comitters are from Apache-OFBiz
>
> I see , sounds like something possbile as long the license is
> respected. The level would be the same than trunk of branches
> ie under https://svn.apache.org/repos/asf/ofbiz and could be /plugin
>
> To be discussed futher by the community, versionning comes OOTB, but
> being in sync with releases and trunk would be another beast. I guess
> you have your tools for that, license?

Apache 2.0 of course (as it's explain in the mail "OFBiz Plugin
Management, status and propositions" ;-)

>
> Jacques
>
>>>
>>> Jacques
>>>
>>>>>
>>>>> Jacques
>>>>
>>>
>>
>

[Anne Jessel]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
> >> <[hidden email]> 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: [phone]
> > Fax: [phone]
> > Web: http://www.cohsoft.com.au/
> > Email: [hidden email]
> >
> > Bonsai ERP, the all-inclusive ERP system
> > http://www.bonsaierp.com.au/
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

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

[Mansour]

Thank you Anne.
Perfect.
I think options like this can be made visible through some documentation.
At least inside the code through comments.
I know it's there for BIRT.



On Sun, Mar 25, 2012 at 8:09 PM, Anne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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
>> >> <[hidden email]> 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: [phone]
>> > Fax: [phone]
>> > Web: http://www.cohsoft.com.au/
>> > Email: [hidden email]
>> >
>> > Bonsai ERP, the all-inclusive ERP system
>> > http://www.bonsaierp.com.au/
>>
>
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Phone: [phone]
> Fax: [phone]
> Web: http://www.cohsoft.com.au/
> Email: [hidden email]
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/

[Jacques Le Roux]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>> <[hidden email]> 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: [phone]
>>> Fax: [phone]
>>> Web: http://www.cohsoft.com.au/
>>> Email: [hidden email]
>>>
>>> Bonsai ERP, the all-inclusive ERP system
>>> http://www.bonsaierp.com.au/

[Scott Gray-2]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>> <[hidden email]> 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: [phone]
>>>> Fax: [phone]
>>>> Web: http://www.cohsoft.com.au/
>>>> Email: [hidden email]
>>>>
>>>> Bonsai ERP, the all-inclusive ERP system
>>>> http://www.bonsaierp.com.au/

[Divesh Dutta]

Comments inline:


On Mar 20, 2012, at 5:18 PM, Jacopo Cappellato wrote:

>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>
>
> Jacques proposed to keep Tomahawk (default) and Flat Grey.
> Olivier proposed to keep just one (Tomahawk, I guess).
> No other comments so far.
> What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this.

I agree to add other themes in Extras. More because its goes with the idea of using a resource as plugin and putting them in extras.

Thanks
--
Divesh


>
> Jacopo

[Divesh Dutta]

+1 for Adrian.

IT departments use specific tools. And they would like to integrate those tools with OFBiz. So any reporting tool should go in Extras and End User should download them as per their need. We just need good documentation around all these efforts to help end users.

Thanks
--
Divesh

On Mar 20, 2012, at 8:01 PM, [hidden email] wrote:

> I like the idea of keeping reporting tools separate from OFBiz. In my experience, IT departments are already using a reporting tool for other applications and they would prefer to integrate that tool with OFBiz, instead of learning/using a new tool that comes bundled with it.
>
> -Adrian
>
> Quoting Jacopo Cappellato <[hidden email]>:
>
>>>
>>> L) framework/birt (and related dependencies/reports spread around): move to "Extras"
>>>
>>> M) framework/bi (and related dependencies - ecas/business rules and data - spread around): move to "Extras"
>>>
>>
>> This is an area where Hans and I are in disagreement and we didn't get much feedback from others.
>>
>> So I would like to explain here why I think we should move the Birt component and the Birt reports out of the framework and consider them as optional tools.
>>
>> There are currently 18 reports in the applications implemented with Birt; but they really seem experiments rather than something really usable; to give you some examples:
>>
>> * in most of them there is this code like this:
>>
>> userLogin = null;
>> try {
>>    userLogin = delegator.findByPrimaryKey("UserLogin",UtilMisc.toMap("userLoginId","admin"));
>> } catch(e) {
>>        Debug.logError(e,"");
>> }
>>
>> * all the retrieval logic (scripts) is inlined with layout definition and this is something we try to avoid in all the existing screens
>> * entity list iterators are not properly closed
>> * some of the widget based financial reports have been converted to Birt: their layout is still very simple and comparable to the widget based versions available before Birt; so the conversion to Birt added a dependencies on this component without adding real value (the rptdesign files mix together data preparation scripts and ui definitions and in order to maintain them you have to use the Birt designer); also some of them are now broken: Income Stetements, Balance Sheet etc... This is probably caused by the recent refactoring of JSR-223 but the original widget based PDF are still there and are working fine...
>> * building a report with this Birt integration still requires a lot of development work (similar to the one required to create a screen); but then the code in the rptdesign is very difficult to maintain without the editor
>>
>> My questions are:
>> * do you really think that this way of integrating rptdesign reports is the answer to fill the gap of a good reporting tool in OFBiz? Are you actually using this integration for your reports?
>> * do we all agree to make this Birt integration the best practice mechanism for all OFBiz reports?
>> * do you really think that we should replace all the existing widget generated reports and FOP reports with rptdesign reports built using the existing Birt integration under the framework?
>>
>> If any of your answers will be "no" then in my opinion it would be much better to:
>> 1) make Birt integration an optional component, downloaded separately
>> 2) move the existing rptdesign reports out of the applications and keep them in the external Birt component
>> 3) at this point users will have the option to use the Birt component or not, but the ootb code will be clean and without dependencies on it; most of all, we will not deliver reports that looks similar (ugly) but they are implemented randomly with Birt or Widgets
>> 4) start evaluating, as a community, what should be the best practices for ootb reports: what is the tool we want, what are the minimal requirements etc... and then work together to get it in place and then migrate all existing reports to it in order to have a consistent system; if the community will not be able to reach a consensus on this, then we should leave the decision about the reporting tool to use to the end user
>>
>> I think that the Birt integration is a nice optional component, and I see that there may be interested parties, but in its current status it is not something ready for becoming the primary reporting tool for the ootb applications.
>>
>> Jacopo
>
>
>

[Divesh Dutta]

I second with Scott. I would like to see E-commerce component in Special Purpose because that is the most commonly used component and its code should be well managed. Lots of people see E-commerce as reference application made on top of OFBiz. So having  Ecommerce's code managed by Committers is good idea.

+1 for moving POS in Extras.

Thanks
--
Divesh

On Mar 21, 2012, at 12:59 AM, Scott Gray wrote:

> I'm in favor of moving all special purpose apps to Extras (or Attic for some of the older/unused ones) except for ecommerce.  Even then the only reason I'd like to keep ecommerce is because it is the only special purpose app that is almost universally useful to OFBiz users and I'd like to keep it under our control for now at least.
>
> So I'd like to see pos moved to Extras and perhaps these users of it can step up and help maintain it.
>
> Regards
> Scott
>
> On 21/03/2012, at 4:21 AM, Jacopo Cappellato wrote:
>
>> Makes sense
>>
>> Jacopo
>>
>> On Mar 20, 2012, at 3:58 PM, Jacques Le Roux wrote:
>>
>>> From: "Jacopo Cappellato" <[hidden email]>
>>>>> A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component
>>>>>
>>>>> B) specialpurpose/pos: move to "Extras"
>>>>>
>>>>
>>>> No one objected so far; Jacques offered his help for #A.
>>>> Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components?
>>>
>>> Yes, I know there are POS users out there. So I now wonder if we should not wait before moving it out of specialpurpose. When you think about it, it's the twin of eCommerce. With a bit more involvment though, mostly because of its relation with Entity Sync (maintenance) which is actually part of the framework (entityext component).
>>>
>>> Jacques
>>
>