Lose Weight Program for OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.

We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...

Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.

The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
And this is exactly what we have now:
* high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
* stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product

The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.

It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.

OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...

I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.

In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.

IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
* can the component be easily removed by the project? is it independent and can live outside as a plugin?
* do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
* is this feature used by other code in the system?
* is the feature functional? or is it largely incomplete?
* is this an old component/code?
* is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)

DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.

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"

And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):

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"

C) $OFBIZ_HOME/debian: move to "Attic"

D) the seleniumxml code in framework/testtools: move to "Attic"

E) specialpurpose/workflow: move to "Attic"

F) specialpurpose/shark: move to "Attic"

G) specialpurpose/ofbizwebsite: move to "Attic"

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"

I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)

J) framework/appserver: move to "Extras"

K) framework/jetty: move to "Extras" (or "Attic")

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"

N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"

O) framework/documents: move the content to Wiki and then move to "Attic"

P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool

Q) framework/example and framework/exampleext: move to specialpurpose

Kind regards,

Jacopo

Re: Lose Weight Program for OFBiz

[Olivier Heintz <ho...@nereide.biz>]

Le 18/03/2012 10:10, Jacopo Cappellato a écrit :
> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>
> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>
> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>
> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
> And this is exactly what we have now:
> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
It's true because there is no way in a "large application" to know who 
are available to maintain this part of code or who is using it. So one 
of main conclusion is to manage more small piece of "code", to be sure a 
committer in a project is responsible for all the Project.
> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>
> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>
> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>
> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.

> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>
> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
> * is this feature used by other code in the system?
> * is the feature functional? or is it largely incomplete?
> * is this an old component/code?
> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>
> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
To avoid that some feel attacked or judged by the removing of a piece of 
code, it seems to me very important that all portions of code that is 
removed or move can be easily maintained (in parallel to OFBiz) by one 
who wishes.
If it's a full component, it's currently easy.
If it's a functionality or a technical part (ex: Birt) it's currently 
possible but it's more complex to maintain the relative report in the 
different end user application (in OFBiz) which used it
if it's a functionality, such as rental, it's currently very complex to 
maintain it in parallel to OFBiz

I am convinced that the proper evaluation of the usefulness and / or use 
of a feature is:
1) is there enough contributors - maintainers
2) is there enough users

There will inevitably be errors in this (very good) approach to weight 
loss. So, we also need the right tool to be able to correct them.

In parallel with this work to classify Code which is Used or Not, I 
propose to start a second thread about OFBiz Plugin Management, what is 
available and what is needed before removing or moving some components 
(or part of component)
> 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"
>
> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>
> 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"
>
> C) $OFBIZ_HOME/debian: move to "Attic"
>
> D) the seleniumxml code in framework/testtools: move to "Attic"
>
> E) specialpurpose/workflow: move to "Attic"
>
> F) specialpurpose/shark: move to "Attic"
>
> G) specialpurpose/ofbizwebsite: move to "Attic"
>
> 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"
>
> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>
> J) framework/appserver: move to "Extras"
>
> K) framework/jetty: move to "Extras" (or "Attic")
>
> 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"
>
> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>
> O) framework/documents: move the content to Wiki and then move to "Attic"
>
> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>
> Q) framework/example and framework/exampleext: move to specialpurpose
>
> Kind regards,
>
> Jacopo
>
>

Re: Lose Weight Program for OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

I think that the slim down approach we are trying to implement, will help if and when we will decide to migrate to Moqui: Moqui is already a slimmed down framework and if our ootb applications will not rely on a fat framework will be easy to migrate;  also having less code to maintain and migrate will make the migration to Moqui a more viable option for the community. Of course the migration to Moqui will represent a revolutionary approach that would be carefully evaluated with the community while this slim down roadmap is an evolution (that can be done in steps) that is not alternative to the switch to Moqui.

Jacopo

On Mar 20, 2012, at 10:28 AM, Hans Bakker wrote:

> Jacopo,
> 
> there is another alternative not listed here:
> Use the Moqui approach and separate in
> 
> 1. framework,
> 2. services and entities
> 3. application components
> 
> and concider a conversion path to the moqui framework.
> 
> Regards
> Hans
> 
> 
> On 03/20/2012 04:15 PM, Jacopo Cappellato wrote:
>> Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared.
>> 
>> There seems to be a general agreement (with exceptions) about the following points:
>> * the size of OFBiz should be reduced
>> * some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them)
>> * some components/features can go to Extras
>> * the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately)
>> 
>> I am starting separate threads to discuss specific topics/actionable items.
>> 
>> Kind regards,
>> 
>> Jacopo
>> 
>> On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote:
>> 
>>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>>> 
>>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>> 
>>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>>> 
>>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>>> And this is exactly what we have now:
>>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>>> 
>>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>>> 
>>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>>> 
>>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>>> 
>>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>>> 
>>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>>> 
>>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>>> * is this feature used by other code in the system?
>>> * is the feature functional? or is it largely incomplete?
>>> * is this an old component/code?
>>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>>> 
>>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>>> 
>>> 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"
>>> 
>>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>>> 
>>> 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"
>>> 
>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>> 
>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>> 
>>> E) specialpurpose/workflow: move to "Attic"
>>> 
>>> F) specialpurpose/shark: move to "Attic"
>>> 
>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>> 
>>> 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"
>>> 
>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>> 
>>> J) framework/appserver: move to "Extras"
>>> 
>>> K) framework/jetty: move to "Extras" (or "Attic")
>>> 
>>> 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"
>>> 
>>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>>> 
>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>> 
>>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>>> 
>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>> 
>>> Kind regards,
>>> 
>>> Jacopo
>>> 
> 

Re: Lose Weight Program for OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On Mar 20, 2012, at 10:28 AM, Hans Bakker wrote:

> Use the Moqui approach and separate in
> 
> 1. framework,
> 2. services and entities
> 3. application components

By the way, as I mentioned in another thread, I like very much the idea above of having a lighter framework, a library of generic services and entities and *one* ERP component/application that represents the implementation of a specific ERP system that is still rather generic/configurable (but not too much, we could build it considering a medium company in the retail industry purchasing/manufacturing/selling different types of products like services and goods and most of all we should give up pretending that what we have right now can be used to serve a universal company or be extended to serve virtually any company in the World)... similar to the existing applications but much cleaner; then some add ons (external to the above layers) could add reporting/etc... capabilities or add external specialized applications (e.g. steel industry, scrum, paper industry etc...).

Jacopo

Re: Lose Weight Program for OFBiz

[Hans Bakker <ma...@antwebsystems.com>]

Jacopo,

there is another alternative not listed here:
Use the Moqui approach and separate in

1. framework,
2. services and entities
3. application components

and concider a conversion path to the moqui framework.

Regards
Hans


On 03/20/2012 04:15 PM, Jacopo Cappellato wrote:
> Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared.
>
> There seems to be a general agreement (with exceptions) about the following points:
> * the size of OFBiz should be reduced
> * some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them)
> * some components/features can go to Extras
> * the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately)
>
> I am starting separate threads to discuss specific topics/actionable items.
>
> Kind regards,
>
> Jacopo
>
> On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote:
>
>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>>
>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>
>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>>
>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>> And this is exactly what we have now:
>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>>
>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>>
>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>>
>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>>
>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>>
>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>>
>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>> * is this feature used by other code in the system?
>> * is the feature functional? or is it largely incomplete?
>> * is this an old component/code?
>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>>
>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>>
>> 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"
>>
>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>>
>> 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"
>>
>> C) $OFBIZ_HOME/debian: move to "Attic"
>>
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>
>> E) specialpurpose/workflow: move to "Attic"
>>
>> F) specialpurpose/shark: move to "Attic"
>>
>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>
>> 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"
>>
>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>
>> J) framework/appserver: move to "Extras"
>>
>> K) framework/jetty: move to "Extras" (or "Attic")
>>
>> 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"
>>
>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>>
>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>
>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>>
>> Q) framework/example and framework/exampleext: move to specialpurpose
>>
>> Kind regards,
>>
>> Jacopo
>>

Re: Lose Weight Program for OFBiz

[Olivier Heintz <ho...@nereide.biz>]

Le 20/03/2012 10:15, Jacopo Cappellato a écrit :
> Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared.
>
> There seems to be a general agreement (with exceptions) about the following points:
> * the size of OFBiz should be reduced
> * some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them)
> * some components/features can go to Extras
> * the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately)
in the plug-in approach don't forget Apache-OFBiz sub-project for 
plug-in done with all it's needed in Apache approach (best practice, 
user help, large community, ....)
> I am starting separate threads to discuss specific topics/actionable items.
>
> Kind regards,
>
> Jacopo
>
> On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote:
>
>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>>
>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>
>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>>
>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>> And this is exactly what we have now:
>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>>
>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>>
>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>>
>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>>
>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>>
>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>>
>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>> * is this feature used by other code in the system?
>> * is the feature functional? or is it largely incomplete?
>> * is this an old component/code?
>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>>
>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>>
>> 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"
>>
>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>>
>> 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"
>>
>> C) $OFBIZ_HOME/debian: move to "Attic"
>>
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>
>> E) specialpurpose/workflow: move to "Attic"
>>
>> F) specialpurpose/shark: move to "Attic"
>>
>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>
>> 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"
>>
>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>
>> J) framework/appserver: move to "Extras"
>>
>> K) framework/jetty: move to "Extras" (or "Attic")
>>
>> 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"
>>
>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>>
>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>
>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>>
>> Q) framework/example and framework/exampleext: move to specialpurpose
>>
>> Kind regards,
>>
>> Jacopo
>>
>

Re: Lose Weight Program for OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared.

There seems to be a general agreement (with exceptions) about the following points:
* the size of OFBiz should be reduced
* some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them)
* some components/features can go to Extras
* the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately)

I am starting separate threads to discuss specific topics/actionable items.

Kind regards,

Jacopo

On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote:

> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
> 
> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
> 
> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
> 
> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
> And this is exactly what we have now:
> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
> 
> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
> 
> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
> 
> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
> 
> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
> 
> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
> 
> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
> * is this feature used by other code in the system?
> * is the feature functional? or is it largely incomplete?
> * is this an old component/code?
> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
> 
> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
> 
> 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"
> 
> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
> 
> 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"
> 
> C) $OFBIZ_HOME/debian: move to "Attic"
> 
> D) the seleniumxml code in framework/testtools: move to "Attic"
> 
> E) specialpurpose/workflow: move to "Attic"
> 
> F) specialpurpose/shark: move to "Attic"
> 
> G) specialpurpose/ofbizwebsite: move to "Attic"
> 
> 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"
> 
> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
> 
> J) framework/appserver: move to "Extras"
> 
> K) framework/jetty: move to "Extras" (or "Attic")
> 
> 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"
> 
> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
> 
> O) framework/documents: move the content to Wiki and then move to "Attic"
> 
> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
> 
> Q) framework/example and framework/exampleext: move to specialpurpose
> 
> Kind regards,
> 
> Jacopo
> 

Lose Weight Program for OFBiz - datafile

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
> 

There seems to be a general consensus to keep the component as is.

Jacopo

Re: Lose Weight Program for OFBiz - ofbizwebsite

[Olivier Heintz <ho...@nereide.biz>]

Le 21/03/2012 15:03, Hans Bakker a écrit :
> Jacques,
>
> sure  at the time is was up-to-date and this was a proposal how we can 
> use ofbiz for the website, however because of the strict apache rules 
> it was not used...but can still be a template for any local ofbiz 
> website.....
>
> It remains weak: being an 'ofbiz' provider but not using it yourself.....
>
imo it's a good cms ofbiz capability demonstration, so +1 for extras :-)
> Regards,
> Hans
>
> On 03/21/2012 08:55 PM, Jacques Le Roux wrote:
>> Hans,
>>
>> The problem is that it's completly outdated and nobody is able/want 
>> to maintain it
>>
>> Just compare with http://ofbiz.apache.org/ which follows ASF rules 
>> with for instance a TM on Logo, etc.
>>
>> Jacques
>>
>> From: "Hans Bakker" <ma...@antwebsystems.com>
>>> ---- then this could be in contrast with the ASF infrastructure 
>>> offered to the projects. -----
>>>
>>> ??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/
>>>
>>> Regards,
>>> Hans
>>>
>>> On 03/20/2012 06:48 PM, Jacopo Cappellato wrote:
>>>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>>>
>>>> Jacques and Olivier proposed to move it to Extras instead just in 
>>>> case someone will pick up the work and complete it in the future.
>>>> I would like to mention that, if the original goal was "to eat our 
>>>> own dog food" and run the OFBiz site on it, then this could be in 
>>>> contrast with the ASF infrastructure offered to the projects.
>>>>
>>>> Jacopo
>>>
>
>

Re: Lose Weight Program for OFBiz - ofbizwebsite

[Pierre Smits <pi...@gmail.com>]

Hans,

The OFBiz project can hardly be regarded as an OFBiz Provider. Look at the
list of Providers on the site. Then look at the source of their websites
and have a feel for how many (besides your company) use OFBiz as a WCM.

There are several solutions in the field providing for website
functionality. Some of which including a richer set of functionality and
better user experience.

Regards,

Pierre

Op 21 maart 2012 15:03 schreef Hans Bakker
<ma...@antwebsystems.com>het volgende:

> Jacques,
>
> sure  at the time is was up-to-date and this was a proposal how we can use
> ofbiz for the website, however because of the strict apache rules it was
> not used...but can still be a template for any local ofbiz website.....
>
> It remains weak: being an 'ofbiz' provider but not using it yourself.....
>
> Regards,
> Hans
>
>
> On 03/21/2012 08:55 PM, Jacques Le Roux wrote:
>
>> Hans,
>>
>> The problem is that it's completly outdated and nobody is able/want to
>> maintain it
>>
>> Just compare with http://ofbiz.apache.org/ which follows ASF rules with
>> for instance a TM on Logo, etc.
>>
>> Jacques
>>
>> From: "Hans Bakker" <mailinglist@antwebsystems.com**>
>>
>>> ---- then this could be in contrast with the ASF infrastructure offered
>>> to the projects. -----
>>>
>>> ??? try: http://demo-trunk.ofbiz.**apache.org/ofbiz/<http://demo-trunk.ofbiz.apache.org/ofbiz/>
>>>
>>> Regards,
>>> Hans
>>>
>>> On 03/20/2012 06:48 PM, Jacopo Cappellato wrote:
>>>
>>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>>>
>>>>>  Jacques and Olivier proposed to move it to Extras instead just in
>>>> case someone will pick up the work and complete it in the future.
>>>> I would like to mention that, if the original goal was "to eat our own
>>>> dog food" and run the OFBiz site on it, then this could be in contrast with
>>>> the ASF infrastructure offered to the projects.
>>>>
>>>> Jacopo
>>>>
>>>
>>>
>

Re: Lose Weight Program for OFBiz - ofbizwebsite

[Hans Bakker <ma...@antwebsystems.com>]

Jacques,

sure  at the time is was up-to-date and this was a proposal how we can 
use ofbiz for the website, however because of the strict apache rules it 
was not used...but can still be a template for any local ofbiz website.....

It remains weak: being an 'ofbiz' provider but not using it yourself.....

Regards,
Hans

On 03/21/2012 08:55 PM, Jacques Le Roux wrote:
> Hans,
>
> The problem is that it's completly outdated and nobody is able/want to 
> maintain it
>
> Just compare with http://ofbiz.apache.org/ which follows ASF rules 
> with for instance a TM on Logo, etc.
>
> Jacques
>
> From: "Hans Bakker" <ma...@antwebsystems.com>
>> ---- then this could be in contrast with the ASF infrastructure 
>> offered to the projects. -----
>>
>> ??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/
>>
>> Regards,
>> Hans
>>
>> On 03/20/2012 06:48 PM, Jacopo Cappellato wrote:
>>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>>
>>> Jacques and Olivier proposed to move it to Extras instead just in 
>>> case someone will pick up the work and complete it in the future.
>>> I would like to mention that, if the original goal was "to eat our 
>>> own dog food" and run the OFBiz site on it, then this could be in 
>>> contrast with the ASF infrastructure offered to the projects.
>>>
>>> Jacopo
>>

Re: Lose Weight Program for OFBiz - ofbizwebsite

[Jacques Le Roux <ja...@les7arts.com>]

Hans,

The problem is that it's completly outdated and nobody is able/want to maintain it

Just compare with http://ofbiz.apache.org/ which follows ASF rules with for instance a TM on Logo, etc.

Jacques

From: "Hans Bakker" <ma...@antwebsystems.com>
> ---- then this could be in contrast with the ASF infrastructure offered to the projects. -----
>
> ??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/
>
> Regards,
> Hans
>
> On 03/20/2012 06:48 PM, Jacopo Cappellato wrote:
>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>
>> Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the 
>> future.
>> I would like to mention that, if the original goal was "to eat our own dog food" and run the OFBiz site on it, then this could be 
>> in contrast with the ASF infrastructure offered to the projects.
>>
>> Jacopo
> 

Re: Lose Weight Program for OFBiz - ofbizwebsite

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Infra wouldn't be happy if we host the website in that demo instance; websites potentially have a lot of visits and that server is not intended for the load; this is similar to Confluence based pages: we will no more be allowed to use direct links to them from the website.

Jacopo

On Mar 21, 2012, at 11:46 AM, Hans Bakker wrote:

> ---- then this could be in contrast with the ASF infrastructure offered to the projects. -----
> 
> ??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/
> 
> Regards,
> Hans
> 
> On 03/20/2012 06:48 PM, Jacopo Cappellato wrote:
>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>> 
>> Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future.
>> I would like to mention that, if the original goal was "to eat our own dog food" and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects.
>> 
>> Jacopo
> 

Re: Lose Weight Program for OFBiz - ofbizwebsite

[Hans Bakker <ma...@antwebsystems.com>]

---- then this could be in contrast with the ASF infrastructure offered 
to the projects. -----

??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/

Regards,
Hans

On 03/20/2012 06:48 PM, Jacopo Cappellato wrote:
>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>
> Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future.
> I would like to mention that, if the original goal was "to eat our own dog food" and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects.
>
> Jacopo

Re: Lose Weight Program for OFBiz - ofbizwebsite

[Jacques Le Roux <ja...@les7arts.com>]

From: "Scott Gray" <sc...@hotwaxmedia.com>
> On 21/03/2012, at 9:24 AM, Erwan de FERRIERES wrote:
>
>> Le 20/03/2012 12:48, Jacopo Cappellato a écrit :
>>>
>>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>>
>>>
>>> Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the
>>> future.
>>> I would like to mention that, if the original goal was "to eat our own dog food" and run the OFBiz site on it, then this could
>>> be in contrast with the ASF infrastructure offered to the projects.
>>>
>>> Jacopo
>> What is missing on this component ?
>> I think we should keep it where it is, but like for JCR, write a small roadmap on what we need. The website is somehow dependent
>> from JCR, if we implement it completely.
>>
>> -- 
>> Erwan de FERRIERES
>> www.nereide.biz
>
> What possible benefit does this component offer to our users?  It's nothing more than a ridiculously large example component.  If
> we were going to keep this in OFBiz we'd need a new component folder, maybe "extremelyspecialpurpose" or perhaps
> "notreallyanypurpose".
>
> +1 for moving to extras if there are any volunteers to maintain it otherwise, +1 for the attic. (This is essentially my vote for
> all the special purpose apps except ecommerce)

This sounds like a wise/experienced suggestion

Jacques

> Regards
> Scott

Re: Lose Weight Program for OFBiz - ofbizwebsite

[Scott Gray <sc...@hotwaxmedia.com>]

On 21/03/2012, at 9:24 AM, Erwan de FERRIERES wrote:

> Le 20/03/2012 12:48, Jacopo Cappellato a écrit :
>> 
>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>> 
>> 
>> Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future.
>> I would like to mention that, if the original goal was "to eat our own dog food" and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects.
>> 
>> Jacopo
> What is missing on this component ?
> I think we should keep it where it is, but like for JCR, write a small roadmap on what we need. The website is somehow dependent from JCR, if we implement it completely.
> 
> -- 
> Erwan de FERRIERES
> www.nereide.biz

What possible benefit does this component offer to our users?  It's nothing more than a ridiculously large example component.  If we were going to keep this in OFBiz we'd need a new component folder, maybe "extremelyspecialpurpose" or perhaps "notreallyanypurpose".

+1 for moving to extras if there are any volunteers to maintain it otherwise, +1 for the attic. (This is essentially my vote for all the special purpose apps except ecommerce)

Regards
Scott

Re: Lose Weight Program for OFBiz - ofbizwebsite

[Erwan de FERRIERES <er...@nereide.fr>]

Le 20/03/2012 12:48, Jacopo Cappellato a écrit :
>
>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>
>
> Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future.
> I would like to mention that, if the original goal was "to eat our own dog food" and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects.
>
> Jacopo
What is missing on this component ?
I think we should keep it where it is, but like for JCR, write a small 
roadmap on what we need. The website is somehow dependent from JCR, if 
we implement it completely.

-- 
Erwan de FERRIERES
www.nereide.biz

Re: Lose Weight Program for OFBiz - ofbizwebsite

[Pierre Smits <pi...@gmail.com>]

+1

Op 20 maart 2012 12:48 schreef Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> het volgende:

>
> > G) specialpurpose/ofbizwebsite: move to "Attic"
> >
>
> Jacques and Olivier proposed to move it to Extras instead just in case
> someone will pick up the work and complete it in the future.
> I would like to mention that, if the original goal was "to eat our own dog
> food" and run the OFBiz site on it, then this could be in contrast with the
> ASF infrastructure offered to the projects.
>
> Jacopo

Lose Weight Program for OFBiz - ofbizwebsite

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

> G) specialpurpose/ofbizwebsite: move to "Attic"
> 

Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future.
I would like to mention that, if the original goal was "to eat our own dog food" and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects.

Jacopo

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Jacques Le Roux <ja...@les7arts.com>]

From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>
>> 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.

Basically I'd keep only eCommerce and POS, maybe asset maintenance (arguments?).
LDAP could be moved IMO, else why not crowd, etc. The less exceptions the better

Jacques 

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Jacques Le Roux <ja...@les7arts.com>]

Hi Anil,

From: "Anil Patel" <an...@hotwaxmedia.com>
>>
>> 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.

I "fear" it will get less exposition and consequently less audience.

Jacques

>
> 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 <an...@hotwaxmedia.com> 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" <ma...@gmail.com>
>>>>> 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
>>>>> <ja...@les7arts.com> wrote:
>>>>>> partymgr is in application will not move, you meant ProjectMgr right?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Mansour Al Akeel" <ma...@gmail.com>
>>>>>>
>>>>>>> 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 <pi...@gmail.com>
>>>>>>> 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 <
>>>>>>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>
>
> 

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Olivier Heintz <ho...@nereide.biz>]

Le 21/03/2012 16:16, Anil Patel a écrit :
>> 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.
As I said in a previous email, imo
1) it's very important for the end-user to be very clear especially for 
the license,
2) for visibility, we should not have too many "project" or 
'repository", so in OFBiz-extras, we should have only a few project, not 
one per plug-in, but one per repository.
example of repository
- all plug-in with a Apache 2.0 license and hight quality level
- all plug-in with a Apache 2.0 license, in development process
- all plug-in with a Apache 2.0 license, with no more activity
- all plug-in with a GPL license and hight quality level
- all plug-in with a GPL license, in development process
- all plug-in coming from a company or community with a associated license
- ...


> 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.
of course, I agree, but only if maturity, support type (large community, 
commercial, ...) license constrain is readable.
> Regards
> Anil Patel
>
>>
>> On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel<an...@hotwaxmedia.com>  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"<ma...@gmail.com>
>>>>> 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
>>>>> <ja...@les7arts.com>  wrote:
>>>>>> partymgr is in application will not move, you meant ProjectMgr right?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Mansour Al Akeel"<ma...@gmail.com>
>>>>>>
>>>>>>> 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<pi...@gmail.com>
>>>>>>> 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<
>>>>>>>> jacopo.cappellato@hotwaxmedia.com>  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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Prince Sewani <pr...@ymail.com>]

+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 <an...@cohsoft.com.au>
To: dev@ofbiz.apache.org 
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 <ma...@gmail.com> 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
> <ja...@les7arts.com> wrote:
> > From: "Mansour Al Akeel" <ma...@gmail.com>
> >>
> >> 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 <
> anil.patel@hotwaxmedia.com>
> >> 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
> >>>> <an...@hotwaxmedia.com> 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" <ma...@gmail.com>
> >>>>>>>
> >>>>>>> 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
> >>>>>>> <ja...@les7arts.com> wrote:
> >>>>>>>>
> >>>>>>>> partymgr is in application will not move, you meant ProjectMgr
> >>>>>>>> right?
> >>>>>>>>
> >>>>>>>> Jacques
> >>>>>>>>
> >>>>>>>> From: "Mansour Al Akeel" <ma...@gmail.com>
> >>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>> <pi...@gmail.com>
> >>>>>>>>> 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 <
> >>>>>>>>>> jacopo.cappellato@hotwaxmedia.com> 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: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sales@cohsoft.com.au

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

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Anne <an...@cohsoft.com.au>]

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 <ma...@gmail.com> 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
> <ja...@les7arts.com> wrote:
> > From: "Mansour Al Akeel" <ma...@gmail.com>
> >>
> >> 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 <
> anil.patel@hotwaxmedia.com>
> >> 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
> >>>> <an...@hotwaxmedia.com> 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" <ma...@gmail.com>
> >>>>>>>
> >>>>>>> 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
> >>>>>>> <ja...@les7arts.com> wrote:
> >>>>>>>>
> >>>>>>>> partymgr is in application will not move, you meant ProjectMgr
> >>>>>>>> right?
> >>>>>>>>
> >>>>>>>> Jacques
> >>>>>>>>
> >>>>>>>> From: "Mansour Al Akeel" <ma...@gmail.com>
> >>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>> <pi...@gmail.com>
> >>>>>>>>> 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 <
> >>>>>>>>>> jacopo.cappellato@hotwaxmedia.com> 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: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sales@cohsoft.com.au

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

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Prince Sewani <pr...@ymail.com>]

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 <ma...@gmail.com>
To: dev@ofbiz.apache.org 
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
<ja...@les7arts.com> wrote:
> From: "Mansour Al Akeel" <ma...@gmail.com>
>>
>> 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 <an...@hotwaxmedia.com>
>> 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
>>>> <an...@hotwaxmedia.com> 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" <ma...@gmail.com>
>>>>>>>
>>>>>>> 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
>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>
>>>>>>>> partymgr is in application will not move, you meant ProjectMgr
>>>>>>>> right?
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> From: "Mansour Al Akeel" <ma...@gmail.com>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> <pi...@gmail.com>
>>>>>>>>> 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 <
>>>>>>>>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Mansour Al Akeel <ma...@gmail.com>]

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
<ja...@les7arts.com> wrote:
> From: "Mansour Al Akeel" <ma...@gmail.com>
>>
>> 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 <an...@hotwaxmedia.com>
>> 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
>>>> <an...@hotwaxmedia.com> 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" <ma...@gmail.com>
>>>>>>>
>>>>>>> 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
>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>
>>>>>>>> partymgr is in application will not move, you meant ProjectMgr
>>>>>>>> right?
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> From: "Mansour Al Akeel" <ma...@gmail.com>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> <pi...@gmail.com>
>>>>>>>>> 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 <
>>>>>>>>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Jacques Le Roux <ja...@les7arts.com>]

From: "Mansour Al Akeel" <ma...@gmail.com>
> 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 <an...@hotwaxmedia.com> 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 <an...@hotwaxmedia.com> 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" <ma...@gmail.com>
>>>>>> 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
>>>>>> <ja...@les7arts.com> wrote:
>>>>>>> partymgr is in application will not move, you meant ProjectMgr right?
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> From: "Mansour Al Akeel" <ma...@gmail.com>
>>>>>>>
>>>>>>>> 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 <pi...@gmail.com>
>>>>>>>> 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 <
>>>>>>>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Mansour Al Akeel <ma...@gmail.com>]

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?
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 <an...@hotwaxmedia.com> 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 <an...@hotwaxmedia.com> 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" <ma...@gmail.com>
>>>>> 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
>>>>> <ja...@les7arts.com> wrote:
>>>>>> partymgr is in application will not move, you meant ProjectMgr right?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Mansour Al Akeel" <ma...@gmail.com>
>>>>>>
>>>>>>> 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 <pi...@gmail.com>
>>>>>>> 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 <
>>>>>>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>
>

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Anil Patel <an...@hotwaxmedia.com>]

> 
> 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 <an...@hotwaxmedia.com> 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" <ma...@gmail.com>
>>>> 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
>>>> <ja...@les7arts.com> wrote:
>>>>> partymgr is in application will not move, you meant ProjectMgr right?
>>>>> 
>>>>> Jacques
>>>>> 
>>>>> From: "Mansour Al Akeel" <ma...@gmail.com>
>>>>> 
>>>>>> 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 <pi...@gmail.com>
>>>>>> 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 <
>>>>>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>> 
>>>> 
>> 

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Mansour Al Akeel <ma...@gmail.com>]

Anil,
I agree with you.

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



On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel <an...@hotwaxmedia.com> 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" <ma...@gmail.com>
>>> 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
>>> <ja...@les7arts.com> wrote:
>>>> partymgr is in application will not move, you meant ProjectMgr right?
>>>>
>>>> Jacques
>>>>
>>>> From: "Mansour Al Akeel" <ma...@gmail.com>
>>>>
>>>>> 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 <pi...@gmail.com>
>>>>> 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 <
>>>>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Anil Patel <an...@hotwaxmedia.com>]

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" <ma...@gmail.com>
>> 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
>> <ja...@les7arts.com> wrote:
>>> partymgr is in application will not move, you meant ProjectMgr right?
>>> 
>>> Jacques
>>> 
>>> From: "Mansour Al Akeel" <ma...@gmail.com>
>>> 
>>>> 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 <pi...@gmail.com>
>>>> 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 <
>>>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>>> 
>>>>>> 
>>>>>> 
>>> 
>> 

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Jacques Le Roux <jl...@les7arts.com>]

They are more generic sure, I wonder for the pos...

Jacques

From: "Mansour Al Akeel" <ma...@gmail.com>
> 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
> <ja...@les7arts.com> wrote:
>> partymgr is in application will not move, you meant ProjectMgr right?
>>
>> Jacques
>>
>> From: "Mansour Al Akeel" <ma...@gmail.com>
>>
>>> 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 <pi...@gmail.com>
>>> 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 <
>>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>>
>>>>>
>>>>>
>>
>

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Mansour Al Akeel <ma...@gmail.com>]

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
<ja...@les7arts.com> wrote:
> partymgr  is in application will not move, you meant ProjectMgr  right?
>
> Jacques
>
> From: "Mansour Al Akeel" <ma...@gmail.com>
>
>> 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 <pi...@gmail.com>
>> 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 <
>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>
>>>>
>>>>
>

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Jacques Le Roux <ja...@les7arts.com>]

partymgr  is in application will not move, you meant ProjectMgr  right?

Jacques

From: "Mansour Al Akeel" <ma...@gmail.com>
>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 <pi...@gmail.com> 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 <
>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>
>>>
>>>

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Mansour Al Akeel <ma...@gmail.com>]

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 <pi...@gmail.com> 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 <
> jacopo.cappellato@hotwaxmedia.com> 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.
>>
>>
>>

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Pierre Smits <pi...@gmail.com>]

+ 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 <
jacopo.cappellato@hotwaxmedia.com> 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.
>
>
>

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Jacques Le Roux <ja...@les7arts.com>]

From: "Nicolas Malin" <ma...@librenberry.net>
> Agree with Jacopo, specialpurpose should be on extras.

Huho? ;o)

> Scrum depend of projectmgr, the OFBiz extra will be have a dependency management to ensure that all needed components will be 
> present.

Good point!
To all:  is crowd dependent on ldap?

Jacques

> Nicolas
>
> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>> 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.
>
>
> -- 
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
>
>
> 

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

[Nicolas Malin <ma...@librenberry.net>]

Agree with Jacopo, specialpurpose should be on extras.
Scrum depend of projectmgr, the OFBiz extra will be have a dependency 
management to ensure that all needed components will be present.

Nicolas

Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>> 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.


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

Lose Weight Program for OFBiz - what should go to specialpurpose

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Lose Weight Program for OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

We will setup a page in the OFBiz website, for sure.
The final decision on the projects that will appear there will be done by the OFBiz PMC but I guess that initially it will only contain projects in Apache Extras; there may be exceptions to to this rule, I guess.

Jacopo

On Mar 21, 2012, at 11:05 AM, Sam Hamilton wrote:

> Where are we going to show the list of addons for OFBiz? Will this only be limited to ones in Apache Extra's or for the people who prefer to do their source hosting on say github join in too? 
> 
> Thanks
> Sam
> 
> 
> On 21 Mar 2012, at 16:23, Vikas Mayur wrote:
> 
>> Thanks Jacopo for your quick response. It clears my doubt.
>> 
>> Regards
>> Vikas
>> 
>> On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote:
>> 
>>> Hi Vikas,
>>> 
>>> I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF):
>>> 
>>> On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote:
>>> 
>>>> Hi Jacopo,
>>>> 
>>>> I have few questions on the proposed idea for Extras.
>>>> 
>>>> -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time?
>>> 
>>> No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement.
>>> 
>>>> 
>>>> -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras.
>>> 
>>> Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there
>>> 
>>>> -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities?
>>> 
>>> I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience
>>> 
>>>> -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz?
>>> 
>>> No
>>> 
>>>> -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not?
>>> 
>>> Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove.
>>> 
>>> Regards,
>>> 
>>> Jacopo
>>> 
>>> 
>>>> 
>>>> Regards
>>>> Vikas
>>>> 
>>>> On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote:
>>>> 
>>>>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>>>>> 
>>>>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>>>>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>>>> 
>>>>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>>>>> 
>>>>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>>>>> And this is exactly what we have now:
>>>>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>>>>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>>>>> 
>>>>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>>>>> 
>>>>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>>>>> 
>>>>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>>>>> 
>>>>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>>>>> 
>>>>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>>>>> 
>>>>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>>>>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>>>>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>>>>> * is this feature used by other code in the system?
>>>>> * is the feature functional? or is it largely incomplete?
>>>>> * is this an old component/code?
>>>>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>>>>> 
>>>>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>>>>> 
>>>>> 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"
>>>>> 
>>>>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>>>>> 
>>>>> 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"
>>>>> 
>>>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>>>> 
>>>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>>>> 
>>>>> E) specialpurpose/workflow: move to "Attic"
>>>>> 
>>>>> F) specialpurpose/shark: move to "Attic"
>>>>> 
>>>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>>> 
>>>>> 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"
>>>>> 
>>>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>>>> 
>>>>> J) framework/appserver: move to "Extras"
>>>>> 
>>>>> K) framework/jetty: move to "Extras" (or "Attic")
>>>>> 
>>>>> 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"
>>>>> 
>>>>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>>>>> 
>>>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>>>> 
>>>>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>>>>> 
>>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>>> 
>>>>> Kind regards,
>>>>> 
>>>>> Jacopo
>>>>> 
>>>> 
>>> 
>> 
> 

Re: Lose Weight Program for OFBiz

[Sam Hamilton <sa...@sh81.com>]

Where are we going to show the list of addons for OFBiz? Will this only be limited to ones in Apache Extra's or for the people who prefer to do their source hosting on say github join in too? 

Thanks
Sam


On 21 Mar 2012, at 16:23, Vikas Mayur wrote:

> Thanks Jacopo for your quick response. It clears my doubt.
> 
> Regards
> Vikas
> 
> On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote:
> 
>> Hi Vikas,
>> 
>> I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF):
>> 
>> On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote:
>> 
>>> Hi Jacopo,
>>> 
>>> I have few questions on the proposed idea for Extras.
>>> 
>>> -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time?
>> 
>> No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement.
>> 
>>> 
>>> -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras.
>> 
>> Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there
>> 
>>> -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities?
>> 
>> I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience
>> 
>>> -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz?
>> 
>> No
>> 
>>> -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not?
>> 
>> Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove.
>> 
>> Regards,
>> 
>> Jacopo
>> 
>> 
>>> 
>>> Regards
>>> Vikas
>>> 
>>> On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote:
>>> 
>>>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>>>> 
>>>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>>>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>>> 
>>>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>>>> 
>>>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>>>> And this is exactly what we have now:
>>>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>>>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>>>> 
>>>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>>>> 
>>>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>>>> 
>>>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>>>> 
>>>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>>>> 
>>>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>>>> 
>>>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>>>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>>>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>>>> * is this feature used by other code in the system?
>>>> * is the feature functional? or is it largely incomplete?
>>>> * is this an old component/code?
>>>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>>>> 
>>>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>>>> 
>>>> 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"
>>>> 
>>>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>>>> 
>>>> 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"
>>>> 
>>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>>> 
>>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>>> 
>>>> E) specialpurpose/workflow: move to "Attic"
>>>> 
>>>> F) specialpurpose/shark: move to "Attic"
>>>> 
>>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>> 
>>>> 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"
>>>> 
>>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>>> 
>>>> J) framework/appserver: move to "Extras"
>>>> 
>>>> K) framework/jetty: move to "Extras" (or "Attic")
>>>> 
>>>> 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"
>>>> 
>>>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>>>> 
>>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>>> 
>>>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>>>> 
>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>> 
>>>> Kind regards,
>>>> 
>>>> Jacopo
>>>> 
>>> 
>> 
> 

Re: Lose Weight Program for OFBiz

[Vikas Mayur <vi...@gmail.com>]

Thanks Jacopo for your quick response. It clears my doubt.

Regards
Vikas

On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote:

> Hi Vikas,
> 
> I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF):
> 
> On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote:
> 
>> Hi Jacopo,
>> 
>> I have few questions on the proposed idea for Extras.
>> 
>> -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time?
> 
> No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement.
> 
>> 
>> -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras.
> 
> Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there
> 
>> -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities?
> 
> I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience
> 
>> -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz?
> 
> No
> 
>> -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not?
> 
> Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove.
> 
> Regards,
> 
> Jacopo
> 
> 
>> 
>> Regards
>> Vikas
>> 
>> On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote:
>> 
>>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>>> 
>>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>> 
>>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>>> 
>>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>>> And this is exactly what we have now:
>>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>>> 
>>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>>> 
>>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>>> 
>>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>>> 
>>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>>> 
>>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>>> 
>>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>>> * is this feature used by other code in the system?
>>> * is the feature functional? or is it largely incomplete?
>>> * is this an old component/code?
>>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>>> 
>>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>>> 
>>> 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"
>>> 
>>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>>> 
>>> 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"
>>> 
>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>> 
>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>> 
>>> E) specialpurpose/workflow: move to "Attic"
>>> 
>>> F) specialpurpose/shark: move to "Attic"
>>> 
>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>> 
>>> 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"
>>> 
>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>> 
>>> J) framework/appserver: move to "Extras"
>>> 
>>> K) framework/jetty: move to "Extras" (or "Attic")
>>> 
>>> 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"
>>> 
>>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>>> 
>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>> 
>>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>>> 
>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>> 
>>> Kind regards,
>>> 
>>> Jacopo
>>> 
>> 
> 

Re: Lose Weight Program for OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Hi Vikas,

I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF):

On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote:

> Hi Jacopo,
> 
> I have few questions on the proposed idea for Extras.
> 
> -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time?

No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement.

> 
> -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras.

Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there

> -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities?

I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience

> -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz?

No

> -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not?

Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove.

Regards,

Jacopo


> 
> Regards
> Vikas
> 
> On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote:
> 
>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>> 
>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>> 
>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>> 
>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>> And this is exactly what we have now:
>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>> 
>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>> 
>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>> 
>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>> 
>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>> 
>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>> 
>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>> * is this feature used by other code in the system?
>> * is the feature functional? or is it largely incomplete?
>> * is this an old component/code?
>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>> 
>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>> 
>> 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"
>> 
>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>> 
>> 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"
>> 
>> C) $OFBIZ_HOME/debian: move to "Attic"
>> 
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>> 
>> E) specialpurpose/workflow: move to "Attic"
>> 
>> F) specialpurpose/shark: move to "Attic"
>> 
>> G) specialpurpose/ofbizwebsite: move to "Attic"
>> 
>> 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"
>> 
>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>> 
>> J) framework/appserver: move to "Extras"
>> 
>> K) framework/jetty: move to "Extras" (or "Attic")
>> 
>> 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"
>> 
>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>> 
>> O) framework/documents: move the content to Wiki and then move to "Attic"
>> 
>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>> 
>> Q) framework/example and framework/exampleext: move to specialpurpose
>> 
>> Kind regards,
>> 
>> Jacopo
>> 
> 

Re: Lose Weight Program for OFBiz

[Vikas Mayur <vi...@gmail.com>]

Hi Jacopo,

I have few questions on the proposed idea for Extras.

-- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time? 
-- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras.
-- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities?
-- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz?
-- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not?

Regards
Vikas

On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote:

> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
> 
> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
> 
> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
> 
> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
> And this is exactly what we have now:
> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
> 
> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
> 
> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
> 
> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
> 
> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
> 
> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
> 
> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
> * is this feature used by other code in the system?
> * is the feature functional? or is it largely incomplete?
> * is this an old component/code?
> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
> 
> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
> 
> 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"
> 
> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
> 
> 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"
> 
> C) $OFBIZ_HOME/debian: move to "Attic"
> 
> D) the seleniumxml code in framework/testtools: move to "Attic"
> 
> E) specialpurpose/workflow: move to "Attic"
> 
> F) specialpurpose/shark: move to "Attic"
> 
> G) specialpurpose/ofbizwebsite: move to "Attic"
> 
> 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"
> 
> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
> 
> J) framework/appserver: move to "Extras"
> 
> K) framework/jetty: move to "Extras" (or "Attic")
> 
> 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"
> 
> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
> 
> O) framework/documents: move the content to Wiki and then move to "Attic"
> 
> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
> 
> Q) framework/example and framework/exampleext: move to specialpurpose
> 
> Kind regards,
> 
> Jacopo
> 

Re: Lose Weight Program for OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On Mar 19, 2012, at 12:26 AM, Anne wrote:

> Basic ideas all look very good to me. IMO anything that is incomplete or
> not maintained should be moved to Attic or Extras, unless there is a very
> good reason for keeping it. The reason for moving it should be well
> documented. That way it is obvious which code needs work. If someone wants
> it, they can fix it and offer to maintain it, and then the community can
> consider whether it is important enough to return.
> 
> Hopefully if non-committers can easily see what areas need work, they'll be
> more likely to adopt some code.
> 
> Cheers,
> Anne.

Anne, I completely agree.
I actually see a few more areas of involvement/participation for the community in this cleanup effort:

1) when this discussion will be finalized, we will have a pretty clear roadmap of cleanup tasks to work one; we will then create Jira tasks for the agreed upon removals and community members (committers and non-committers) will have a chance to assign the tasks to them and help the community to implement the plan; this is really a "roadmap"

2) for components candidate to become projects in the Apache Extras (for OFBiz): we will need at least one project maintainer for each of them: this person doesn't necessarily have to be one of the existing OFBiz committers; I would actually like to see new persons show up and take the leadership; we could then delegate to them to write up (in their Apache Extras" project) the goals for the component (of course we will sync with them)

3) for components that will be simply removed (Attic): I agree about the need to document the status of the code at the time of the removal to give opportunity in the future to an interested person to get them and do some more work

Kind regards,

Jacopo

Re: Lose Weight Program for OFBiz

[Anne <an...@cohsoft.com.au>]

On 19 March 2012 07:15, Scott Gray <sc...@hotwaxmedia.com> wrote:

>   Or perhaps even just tackle each of these consecutively after an
> agreement on the course of action is reached and a volunteer to do the work
> is found then we could move on to the next suggestion?
>
>
+1

Basic ideas all look very good to me. IMO anything that is incomplete or
not maintained should be moved to Attic or Extras, unless there is a very
good reason for keeping it. The reason for moving it should be well
documented. That way it is obvious which code needs work. If someone wants
it, they can fix it and offer to maintain it, and then the community can
consider whether it is important enough to return.

Hopefully if non-committers can easily see what areas need work, they'll be
more likely to adopt some code.

Cheers,
Anne.

-- 
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: sales@cohsoft.com.au

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

Re: Lose Weight Program for OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Thank you Scott.
I will wait a bit more before summarizing some of the concepts/opinion expressed so far and then I will initiate, as you suggested, separate threads.

Jacopo

On Mar 18, 2012, at 9:15 PM, Scott Gray wrote:

> I agree with the concept completely.  I wonder though if each of the suggested changes should get their own thread rather than be discussed in this one, a thread with too many topics flying around is a little difficult to follow.  Or perhaps even just tackle each of these consecutively after an agreement on the course of action is reached and a volunteer to do the work is found then we could move on to the next suggestion?
> 
> Regards
> Scott
> 
> On 18/03/2012, at 10:10 PM, Jacopo Cappellato wrote:
> 
>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>> 
>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>> 
>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>> 
>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>> And this is exactly what we have now:
>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>> 
>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>> 
>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>> 
>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>> 
>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>> 
>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>> 
>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>> * is this feature used by other code in the system?
>> * is the feature functional? or is it largely incomplete?
>> * is this an old component/code?
>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>> 
>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>> 
>> 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"
>> 
>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>> 
>> 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"
>> 
>> C) $OFBIZ_HOME/debian: move to "Attic"
>> 
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>> 
>> E) specialpurpose/workflow: move to "Attic"
>> 
>> F) specialpurpose/shark: move to "Attic"
>> 
>> G) specialpurpose/ofbizwebsite: move to "Attic"
>> 
>> 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"
>> 
>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>> 
>> J) framework/appserver: move to "Extras"
>> 
>> K) framework/jetty: move to "Extras" (or "Attic")
>> 
>> 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"
>> 
>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>> 
>> O) framework/documents: move the content to Wiki and then move to "Attic"
>> 
>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>> 
>> Q) framework/example and framework/exampleext: move to specialpurpose
>> 
>> Kind regards,
>> 
>> Jacopo
>> 
> 

Re: Lose Weight Program for OFBiz

[Scott Gray <sc...@hotwaxmedia.com>]

I agree with the concept completely.  I wonder though if each of the suggested changes should get their own thread rather than be discussed in this one, a thread with too many topics flying around is a little difficult to follow.  Or perhaps even just tackle each of these consecutively after an agreement on the course of action is reached and a volunteer to do the work is found then we could move on to the next suggestion?

Regards
Scott

On 18/03/2012, at 10:10 PM, Jacopo Cappellato wrote:

> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
> 
> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
> 
> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
> 
> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
> And this is exactly what we have now:
> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
> 
> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
> 
> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
> 
> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
> 
> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
> 
> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
> 
> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
> * is this feature used by other code in the system?
> * is the feature functional? or is it largely incomplete?
> * is this an old component/code?
> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
> 
> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
> 
> 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"
> 
> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
> 
> 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"
> 
> C) $OFBIZ_HOME/debian: move to "Attic"
> 
> D) the seleniumxml code in framework/testtools: move to "Attic"
> 
> E) specialpurpose/workflow: move to "Attic"
> 
> F) specialpurpose/shark: move to "Attic"
> 
> G) specialpurpose/ofbizwebsite: move to "Attic"
> 
> 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"
> 
> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
> 
> J) framework/appserver: move to "Extras"
> 
> K) framework/jetty: move to "Extras" (or "Attic")
> 
> 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"
> 
> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
> 
> O) framework/documents: move the content to Wiki and then move to "Attic"
> 
> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
> 
> Q) framework/example and framework/exampleext: move to specialpurpose
> 
> Kind regards,
> 
> Jacopo
> 

Re: Lose Weight Program for OFBiz - example, exampleext

[Jacques Le Roux <ja...@les7arts.com>]

From: <ad...@sandglass-software.com>
>I believe the original purpose of the Example component was to provide  
> a very basic application that new developers can analyze and learn  
> from. Running the ant task creates an empty application - there is  
> nothing to see there.
> 
> So, here is the use case: I need to train new developers to write an  
> OFBiz application, and I need a basic functional application to point  
> them to. The training could occur with a framework-only instance of  
> OFBiz.

This makes sense, but then why in framework and not whole in specialpurporse?
If we slim down specialpurpose, this should not make a huge difference.

Jacques
 
> -Adrian
> 
> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:
> 
>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>
>> Adrian would like to keep Example in the framework but slim it down  
>> a lot to the essential (no form widgets examples, no Ajax examples,  
>> no content examples etc...). Adrian would you please confirm if in  
>> your vision the "example" application should document the layout of  
>> a typical OFBiz component only? If yes, we could use the output of  
>> the "ant create-component" task to document the best practice layout.
>> Jacques, Olivier would like to keep also the examples for the  
>> various higher level features available to OFBiz applications.
>>
>> I think that from the discussion it could emerge the following  
>> solution to please everyone:
>>
>> * keep the "example" component in the framework but slim it down to  
>> the bare essential
>> * move the "exampleext" component to specialpurpose and migrate to  
>> it all the extra features: this could also be used as a best  
>> practice guide on how to extend a component from  
>> hot-deploy/specialpurpose
>>
>> I still think that it would be nicer to not bundle the "example"  
>> component ootb to keep the framework cleaner: the example should be  
>> downloaded separately (when we will have clear separation between  
>> framework and the rest); this approach is similar to tomcat and its  
>> example applications. But I don't have a strong opinion on this.
>>
>> Jacopo
>>
>>
> 
> 
>

Re: Lose Weight Program for OFBiz - example, exampleext

[ad...@sandglass-software.com]

Yes, making it an extra is an option.

-Adrian

Quoting Mansour Al Akeel <ma...@gmail.com>:

> is it possible to download the "example" separately for new comers ?
>
>
>
> On Tue, Mar 20, 2012 at 10:28 AM,   
> <ad...@sandglass-software.com> wrote:
>> I believe the original purpose of the Example component was to provide a
>> very basic application that new developers can analyze and learn from.
>> Running the ant task creates an empty application - there is nothing to see
>> there.
>>
>> So, here is the use case: I need to train new developers to write an OFBiz
>> application, and I need a basic functional application to point them to. The
>> training could occur with a framework-only instance of OFBiz.
>>
>> -Adrian
>>
>>
>> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:
>>
>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>
>>>
>>> Adrian would like to keep Example in the framework but slim it down a lot
>>> to the essential (no form widgets examples, no Ajax examples, no content
>>> examples etc...). Adrian would you please confirm if in your vision the
>>> "example" application should document the layout of a typical OFBiz
>>> component only? If yes, we could use the output of the "ant
>>> create-component" task to document the best practice layout.
>>> Jacques, Olivier would like to keep also the examples for the various
>>> higher level features available to OFBiz applications.
>>>
>>> I think that from the discussion it could emerge the following solution to
>>> please everyone:
>>>
>>> * keep the "example" component in the framework but slim it down to the
>>> bare essential
>>> * move the "exampleext" component to specialpurpose and migrate to it all
>>> the extra features: this could also be used as a best practice guide on how
>>> to extend a component from hot-deploy/specialpurpose
>>>
>>> I still think that it would be nicer to not bundle the "example" component
>>> ootb to keep the framework cleaner: the example should be downloaded
>>> separately (when we will have clear separation between framework and the
>>> rest); this approach is similar to tomcat and its example applications. But
>>> I don't have a strong opinion on this.
>>>
>>> Jacopo
>>>
>>>
>>
>>
>>
>

Re: Lose Weight Program for OFBiz - example, exampleext

[Mansour Al Akeel <ma...@gmail.com>]

is it possible to download the "example" separately for new comers ?



On Tue, Mar 20, 2012 at 10:28 AM,  <ad...@sandglass-software.com> wrote:
> I believe the original purpose of the Example component was to provide a
> very basic application that new developers can analyze and learn from.
> Running the ant task creates an empty application - there is nothing to see
> there.
>
> So, here is the use case: I need to train new developers to write an OFBiz
> application, and I need a basic functional application to point them to. The
> training could occur with a framework-only instance of OFBiz.
>
> -Adrian
>
>
> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:
>
>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>
>>
>> Adrian would like to keep Example in the framework but slim it down a lot
>> to the essential (no form widgets examples, no Ajax examples, no content
>> examples etc...). Adrian would you please confirm if in your vision the
>> "example" application should document the layout of a typical OFBiz
>> component only? If yes, we could use the output of the "ant
>> create-component" task to document the best practice layout.
>> Jacques, Olivier would like to keep also the examples for the various
>> higher level features available to OFBiz applications.
>>
>> I think that from the discussion it could emerge the following solution to
>> please everyone:
>>
>> * keep the "example" component in the framework but slim it down to the
>> bare essential
>> * move the "exampleext" component to specialpurpose and migrate to it all
>> the extra features: this could also be used as a best practice guide on how
>> to extend a component from hot-deploy/specialpurpose
>>
>> I still think that it would be nicer to not bundle the "example" component
>> ootb to keep the framework cleaner: the example should be downloaded
>> separately (when we will have clear separation between framework and the
>> rest); this approach is similar to tomcat and its example applications. But
>> I don't have a strong opinion on this.
>>
>> Jacopo
>>
>>
>
>
>

Re: Lose Weight Program for OFBiz - example, exampleext

[ad...@sandglass-software.com]

I believe the original purpose of the Example component was to provide  
a very basic application that new developers can analyze and learn  
from. Running the ant task creates an empty application - there is  
nothing to see there.

So, here is the use case: I need to train new developers to write an  
OFBiz application, and I need a basic functional application to point  
them to. The training could occur with a framework-only instance of  
OFBiz.

-Adrian

Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:

>> Q) framework/example and framework/exampleext: move to specialpurpose
>
> Adrian would like to keep Example in the framework but slim it down  
> a lot to the essential (no form widgets examples, no Ajax examples,  
> no content examples etc...). Adrian would you please confirm if in  
> your vision the "example" application should document the layout of  
> a typical OFBiz component only? If yes, we could use the output of  
> the "ant create-component" task to document the best practice layout.
> Jacques, Olivier would like to keep also the examples for the  
> various higher level features available to OFBiz applications.
>
> I think that from the discussion it could emerge the following  
> solution to please everyone:
>
> * keep the "example" component in the framework but slim it down to  
> the bare essential
> * move the "exampleext" component to specialpurpose and migrate to  
> it all the extra features: this could also be used as a best  
> practice guide on how to extend a component from  
> hot-deploy/specialpurpose
>
> I still think that it would be nicer to not bundle the "example"  
> component ootb to keep the framework cleaner: the example should be  
> downloaded separately (when we will have clear separation between  
> framework and the rest); this approach is similar to tomcat and its  
> example applications. But I don't have a strong opinion on this.
>
> Jacopo
>
>

Re: Lose Weight Program for OFBiz - example, exampleext

[Jacques Le Roux <ja...@les7arts.com>]

I did not intend to use Maven at all, but good catch and yes for a (possible far) future iteration

Jacques

From: "Mansour Al Akeel" <ma...@gmail.com>
> Ant+Ivy would fit easier with the structure of ofbiz components.
> If we want to move to maven, then a modification to
> org/ofbiz/base/location/FlexibleLocation.java has to be
> done to allow loading resource from a jar file. I am assuming with
> maven, you want to package the whole component in
> a jar file. I think this is good idea, and it will have to done for OSGI anyway.
> But for the moment, I think Ant+Ivy are more suitable.
>
>
>
>
> On Tue, Mar 20, 2012 at 11:38 AM, Jacques Le Roux
> <ja...@les7arts.com> wrote:
>> From: "Nicolas Malin" <ma...@librenberry.net>
>>
>>> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>>>>
>>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>>
>>>> Adrian would like to keep Example in the framework but slim it down a lot
>>>> to the essential (no form widgets examples, no Ajax
>>>> examples, no content examples etc...). Adrian would you please confirm if
>>>> in your vision the "example" application should
>>>> document the layout of a typical OFBiz component only? If yes, we could
>>>> use the output of the "ant create-component" task to
>>>> document the best practice layout.
>>>> Jacques, Olivier would like to keep also the examples for the various
>>>> higher level features available to OFBiz applications.
>>>>
>>>> I think that from the discussion it could emerge the following solution
>>>> to please everyone:
>>>>
>>>> * keep the "example" component in the framework but slim it down to the
>>>> bare essential
>>>> * move the "exampleext" component to specialpurpose and migrate to it all
>>>> the extra features: this could also be used as a best
>>>> practice guide on how to extend a component from
>>>> hot-deploy/specialpurpose
>>>>
>>>> I still think that it would be nicer to not bundle the "example"
>>>> component ootb to keep the framework cleaner: the example should
>>>> be downloaded separately (when we will have clear separation between
>>>> framework and the rest); this approach is similar to tomcat
>>>> and its example applications. But I don't have a strong opinion on this.
>>>>
>>>> Jacopo
>>>
>>> example and exampleext are they useful for production site ?
>>> if Apache OFBiz implement a plugin manager, why don't use ant (or other)
>>> to prepare OFBiz according to its use.
>>>
>>> If you want develop on OFBiz, when you download from svn run : ant
>>> run-install-dev (it's a example ;)) and ant use plugin manager
>>> to resolve all extras project that compose the official OFBiz developer
>>> package.
>>
>>
>> Interesting, it's based on Ivy, right? Did you ever re-consider Maven (I
>> know the historical ;o)?
>> I guess ant+Ivy is more flexible? I prefer it too, but only crossed Maven
>> during a Geronimo developement
>>
>>
>>> [my life]
>>> At this time, I comment all unneeded components as example on production
>>> site. It isn't a problem, just I don't find clean :)
>>> [/my life]
>>
>>
>> Yes, I do the same, and certainly others as well...
>>
>> Jacques
>>
>>
>>
>>> --
>>> Nicolas MALIN
>>> Consultant
>>> Tél : 06.17.66.40.06
>>> Site projet : http://www.neogia.org/
>>> -------
>>> Société LibrenBerry
>>> Tél : 02.48.02.56.12
>>> Site : http://www.librenberry.net/
>>>
>>
> 

Re: Lose Weight Program for OFBiz - example, exampleext

[Olivier Heintz <ho...@nereide.biz>]

discussion on  "OFBiz Plugin Management, status and propositions" should 
be on the corresponding thread

Le 20/03/2012 16:59, Mansour Al Akeel a écrit :
> Ant+Ivy would fit easier with the structure of ofbiz components.
> If we want to move to maven, then a modification to
> org/ofbiz/base/location/FlexibleLocation.java has to be
> done to allow loading resource from a jar file. I am assuming with
> maven, you want to package the whole component in
> a jar file. I think this is good idea, and it will have to done for OSGI anyway.
> But for the moment, I think Ant+Ivy are more suitable.
>
>
>
>
> On Tue, Mar 20, 2012 at 11:38 AM, Jacques Le Roux
> <ja...@les7arts.com>  wrote:
>> From: "Nicolas Malin"<ma...@librenberry.net>
>>
>>> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>> Adrian would like to keep Example in the framework but slim it down a lot
>>>> to the essential (no form widgets examples, no Ajax
>>>> examples, no content examples etc...). Adrian would you please confirm if
>>>> in your vision the "example" application should
>>>> document the layout of a typical OFBiz component only? If yes, we could
>>>> use the output of the "ant create-component" task to
>>>> document the best practice layout.
>>>> Jacques, Olivier would like to keep also the examples for the various
>>>> higher level features available to OFBiz applications.
>>>>
>>>> I think that from the discussion it could emerge the following solution
>>>> to please everyone:
>>>>
>>>> * keep the "example" component in the framework but slim it down to the
>>>> bare essential
>>>> * move the "exampleext" component to specialpurpose and migrate to it all
>>>> the extra features: this could also be used as a best
>>>> practice guide on how to extend a component from
>>>> hot-deploy/specialpurpose
>>>>
>>>> I still think that it would be nicer to not bundle the "example"
>>>> component ootb to keep the framework cleaner: the example should
>>>> be downloaded separately (when we will have clear separation between
>>>> framework and the rest); this approach is similar to tomcat
>>>> and its example applications. But I don't have a strong opinion on this.
>>>>
>>>> Jacopo
>>> example and exampleext are they useful for production site ?
>>> if Apache OFBiz implement a plugin manager, why don't use ant (or other)
>>> to prepare OFBiz according to its use.
>>>
>>> If you want develop on OFBiz, when you download from svn run : ant
>>> run-install-dev (it's a example ;)) and ant use plugin manager
>>> to resolve all extras project that compose the official OFBiz developer
>>> package.
>>
>> Interesting, it's based on Ivy, right? Did you ever re-consider Maven (I
>> know the historical ;o)?
>> I guess ant+Ivy is more flexible? I prefer it too, but only crossed Maven
>> during a Geronimo developement
>>
>>
>>> [my life]
>>> At this time, I comment all unneeded components as example on production
>>> site. It isn't a problem, just I don't find clean :)
>>> [/my life]
>>
>> Yes, I do the same, and certainly others as well...
>>
>> Jacques
>>
>>
>>
>>> --
>>> Nicolas MALIN
>>> Consultant
>>> Tél : 06.17.66.40.06
>>> Site projet : http://www.neogia.org/
>>> -------
>>> Société LibrenBerry
>>> Tél : 02.48.02.56.12
>>> Site : http://www.librenberry.net/
>>>

Re: Lose Weight Program for OFBiz - example, exampleext

[Mansour Al Akeel <ma...@gmail.com>]

Ant+Ivy would fit easier with the structure of ofbiz components.
If we want to move to maven, then a modification to
org/ofbiz/base/location/FlexibleLocation.java has to be
done to allow loading resource from a jar file. I am assuming with
maven, you want to package the whole component in
a jar file. I think this is good idea, and it will have to done for OSGI anyway.
But for the moment, I think Ant+Ivy are more suitable.




On Tue, Mar 20, 2012 at 11:38 AM, Jacques Le Roux
<ja...@les7arts.com> wrote:
> From: "Nicolas Malin" <ma...@librenberry.net>
>
>> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>>>
>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>
>>> Adrian would like to keep Example in the framework but slim it down a lot
>>> to the essential (no form widgets examples, no Ajax
>>> examples, no content examples etc...). Adrian would you please confirm if
>>> in your vision the "example" application should
>>> document the layout of a typical OFBiz component only? If yes, we could
>>> use the output of the "ant create-component" task to
>>> document the best practice layout.
>>> Jacques, Olivier would like to keep also the examples for the various
>>> higher level features available to OFBiz applications.
>>>
>>> I think that from the discussion it could emerge the following solution
>>> to please everyone:
>>>
>>> * keep the "example" component in the framework but slim it down to the
>>> bare essential
>>> * move the "exampleext" component to specialpurpose and migrate to it all
>>> the extra features: this could also be used as a best
>>> practice guide on how to extend a component from
>>> hot-deploy/specialpurpose
>>>
>>> I still think that it would be nicer to not bundle the "example"
>>> component ootb to keep the framework cleaner: the example should
>>> be downloaded separately (when we will have clear separation between
>>> framework and the rest); this approach is similar to tomcat
>>> and its example applications. But I don't have a strong opinion on this.
>>>
>>> Jacopo
>>
>> example and exampleext are they useful for production site ?
>> if Apache OFBiz implement a plugin manager, why don't use ant (or other)
>> to prepare OFBiz according to its use.
>>
>> If you want develop on OFBiz, when you download from svn run : ant
>> run-install-dev (it's a example ;)) and ant use plugin manager
>> to resolve all extras project that compose the official OFBiz developer
>> package.
>
>
> Interesting, it's based on Ivy, right? Did you ever re-consider Maven (I
> know the historical ;o)?
> I guess ant+Ivy is more flexible? I prefer it too, but only crossed Maven
> during a Geronimo developement
>
>
>> [my life]
>> At this time, I comment all unneeded components as example on production
>> site. It isn't a problem, just I don't find clean :)
>> [/my life]
>
>
> Yes, I do the same, and certainly others as well...
>
> Jacques
>
>
>
>> --
>> Nicolas MALIN
>> Consultant
>> Tél : 06.17.66.40.06
>> Site projet : http://www.neogia.org/
>> -------
>> Société LibrenBerry
>> Tél : 02.48.02.56.12
>> Site : http://www.librenberry.net/
>>
>

Re: Lose Weight Program for OFBiz - example, exampleext

[Anil Patel <an...@hotwaxmedia.com>]

I use example component as my reference for best practice guide. Still I think its better placed in Ofbiz Extras.   

Thanks and Regards
Anil Patel
HotWax Media Inc

On Mar 20, 2012, at 10:17 AM, Nicolas Malin wrote:

> Le 20/03/2012 16:38, Jacques Le Roux a écrit :
>> From: "Nicolas Malin" <ma...@librenberry.net>
>>> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>> Adrian would like to keep Example in the framework but slim it down a lot to the essential (no form widgets examples, no Ajax
>>>> examples, no content examples etc...). Adrian would you please confirm if in your vision the "example" application should
>>>> document the layout of a typical OFBiz component only? If yes, we could use the output of the "ant create-component" task to
>>>> document the best practice layout.
>>>> Jacques, Olivier would like to keep also the examples for the various higher level features available to OFBiz applications.
>>>> 
>>>> I think that from the discussion it could emerge the following solution to please everyone:
>>>> 
>>>> * keep the "example" component in the framework but slim it down to the bare essential
>>>> * move the "exampleext" component to specialpurpose and migrate to it all the extra features: this could also be used as a best
>>>> practice guide on how to extend a component from hot-deploy/specialpurpose
>>>> 
>>>> I still think that it would be nicer to not bundle the "example" component ootb to keep the framework cleaner: the example should
>>>> be downloaded separately (when we will have clear separation between framework and the rest); this approach is similar to tomcat
>>>> and its example applications. But I don't have a strong opinion on this.
>>>> 
>>>> Jacopo
>>> example and exampleext are they useful for production site ?
>>> if Apache OFBiz implement a plugin manager, why don't use ant (or other) to prepare OFBiz according to its use.
>>> 
>>> If you want develop on OFBiz, when you download from svn run : ant run-install-dev (it's a example ;)) and ant use plugin manager
>>> to resolve all extras project that compose the official OFBiz developer package.
>> 
>> Interesting, it's based on Ivy, right? 
> In my mind yes, but I set an idea not a solution ;)
>> Did you ever re-consider Maven (I know the historical ;o)?
>> I guess ant+Ivy is more flexible? I prefer it too, but only crossed Maven during a Geronimo developement
> I prefer ant + ivy too
> 
>> 
>>> [my life]
>>> At this time, I comment all unneeded components as example on production site. It isn't a problem, just I don't find clean :)
>>> [/my life]
>> 
>> Yes, I do the same, and certainly others as well...
>> 
>> Jacques
>> 
>> 
>>> -- 
>>> Nicolas MALIN
>>> Consultant
>>> Tél : 06.17.66.40.06
>>> Site projet : http://www.neogia.org/
>>> -------
>>> Société LibrenBerry
>>> Tél : 02.48.02.56.12
>>> Site : http://www.librenberry.net/
>>> 
> 
> 
> -- 
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
> 

Re: Lose Weight Program for OFBiz - example, exampleext

[Nicolas Malin <ma...@librenberry.net>]

Le 20/03/2012 16:38, Jacques Le Roux a écrit :
> From: "Nicolas Malin" <ma...@librenberry.net>
>> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>> Adrian would like to keep Example in the framework but slim it down 
>>> a lot to the essential (no form widgets examples, no Ajax
>>> examples, no content examples etc...). Adrian would you please 
>>> confirm if in your vision the "example" application should
>>> document the layout of a typical OFBiz component only? If yes, we 
>>> could use the output of the "ant create-component" task to
>>> document the best practice layout.
>>> Jacques, Olivier would like to keep also the examples for the 
>>> various higher level features available to OFBiz applications.
>>>
>>> I think that from the discussion it could emerge the following 
>>> solution to please everyone:
>>>
>>> * keep the "example" component in the framework but slim it down to 
>>> the bare essential
>>> * move the "exampleext" component to specialpurpose and migrate to 
>>> it all the extra features: this could also be used as a best
>>> practice guide on how to extend a component from 
>>> hot-deploy/specialpurpose
>>>
>>> I still think that it would be nicer to not bundle the "example" 
>>> component ootb to keep the framework cleaner: the example should
>>> be downloaded separately (when we will have clear separation between 
>>> framework and the rest); this approach is similar to tomcat
>>> and its example applications. But I don't have a strong opinion on 
>>> this.
>>>
>>> Jacopo
>> example and exampleext are they useful for production site ?
>> if Apache OFBiz implement a plugin manager, why don't use ant (or 
>> other) to prepare OFBiz according to its use.
>>
>> If you want develop on OFBiz, when you download from svn run : ant 
>> run-install-dev (it's a example ;)) and ant use plugin manager
>> to resolve all extras project that compose the official OFBiz 
>> developer package.
>
> Interesting, it's based on Ivy, right? 
In my mind yes, but I set an idea not a solution ;)
> Did you ever re-consider Maven (I know the historical ;o)?
> I guess ant+Ivy is more flexible? I prefer it too, but only crossed 
> Maven during a Geronimo developement
I prefer ant + ivy too

>
>> [my life]
>> At this time, I comment all unneeded components as example on 
>> production site. It isn't a problem, just I don't find clean :)
>> [/my life]
>
> Yes, I do the same, and certainly others as well...
>
> Jacques
>
>
>> -- 
>> Nicolas MALIN
>> Consultant
>> Tél : 06.17.66.40.06
>> Site projet : http://www.neogia.org/
>> -------
>> Société LibrenBerry
>> Tél : 02.48.02.56.12
>> Site : http://www.librenberry.net/
>>


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

Re: Lose Weight Program for OFBiz - example, exampleext

[Jacques Le Roux <ja...@les7arts.com>]

From: "Nicolas Malin" <ma...@librenberry.net>
> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>> Q) framework/example and framework/exampleext: move to specialpurpose
>> Adrian would like to keep Example in the framework but slim it down a lot to the essential (no form widgets examples, no Ajax
>> examples, no content examples etc...). Adrian would you please confirm if in your vision the "example" application should
>> document the layout of a typical OFBiz component only? If yes, we could use the output of the "ant create-component" task to
>> document the best practice layout.
>> Jacques, Olivier would like to keep also the examples for the various higher level features available to OFBiz applications.
>>
>> I think that from the discussion it could emerge the following solution to please everyone:
>>
>> * keep the "example" component in the framework but slim it down to the bare essential
>> * move the "exampleext" component to specialpurpose and migrate to it all the extra features: this could also be used as a best
>> practice guide on how to extend a component from hot-deploy/specialpurpose
>>
>> I still think that it would be nicer to not bundle the "example" component ootb to keep the framework cleaner: the example should
>> be downloaded separately (when we will have clear separation between framework and the rest); this approach is similar to tomcat
>> and its example applications. But I don't have a strong opinion on this.
>>
>> Jacopo
> example and exampleext are they useful for production site ?
> if Apache OFBiz implement a plugin manager, why don't use ant (or other) to prepare OFBiz according to its use.
>
> If you want develop on OFBiz, when you download from svn run : ant run-install-dev (it's a example ;)) and ant use plugin manager
> to resolve all extras project that compose the official OFBiz developer package.

Interesting, it's based on Ivy, right? Did you ever re-consider Maven (I know the historical ;o)?
I guess ant+Ivy is more flexible? I prefer it too, but only crossed Maven during a Geronimo developement

> [my life]
> At this time, I comment all unneeded components as example on production site. It isn't a problem, just I don't find clean :)
> [/my life]

Yes, I do the same, and certainly others as well...

Jacques


> -- 
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
>

Re: Lose Weight Program for OFBiz - example, exampleext

[Nicolas Malin <ma...@librenberry.net>]

Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>> Q) framework/example and framework/exampleext: move to specialpurpose
> Adrian would like to keep Example in the framework but slim it down a lot to the essential (no form widgets examples, no Ajax examples, no content examples etc...). Adrian would you please confirm if in your vision the "example" application should document the layout of a typical OFBiz component only? If yes, we could use the output of the "ant create-component" task to document the best practice layout.
> Jacques, Olivier would like to keep also the examples for the various higher level features available to OFBiz applications.
>
> I think that from the discussion it could emerge the following solution to please everyone:
>
> * keep the "example" component in the framework but slim it down to the bare essential
> * move the "exampleext" component to specialpurpose and migrate to it all the extra features: this could also be used as a best practice guide on how to extend a component from hot-deploy/specialpurpose
>
> I still think that it would be nicer to not bundle the "example" component ootb to keep the framework cleaner: the example should be downloaded separately (when we will have clear separation between framework and the rest); this approach is similar to tomcat and its example applications. But I don't have a strong opinion on this.
>
> Jacopo
example and exampleext are they useful for production site ?
if Apache OFBiz implement a plugin manager, why don't use ant (or other) 
to prepare OFBiz according to its use.

If you want develop on OFBiz, when you download from svn run : ant 
run-install-dev (it's a example ;)) and ant use plugin manager to 
resolve all extras project that compose the official OFBiz developer 
package.

[my life]
At this time, I comment all unneeded components as example on production 
site. It isn't a problem, just I don't find clean :)
[/my life]

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

Re: Lose Weight Program for OFBiz - example, exampleext

[Pierre Smits <pi...@gmail.com>]

+1 on removal from core (framework), as it doesn't add any value in a
framework. However, having it available as a separate downloadable
application (to be used from hot-deploy or special purpose) would be
beneficiary for newcomers in the development scene.

Regards,

Pierre

Op 20 maart 2012 12:47 schreef Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> het volgende:

> > Q) framework/example and framework/exampleext: move to specialpurpose
>
> Adrian would like to keep Example in the framework but slim it down a lot
> to the essential (no form widgets examples, no Ajax examples, no content
> examples etc...). Adrian would you please confirm if in your vision the
> "example" application should document the layout of a typical OFBiz
> component only? If yes, we could use the output of the "ant
> create-component" task to document the best practice layout.
> Jacques, Olivier would like to keep also the examples for the various
> higher level features available to OFBiz applications.
>
> I think that from the discussion it could emerge the following solution to
> please everyone:
>
> * keep the "example" component in the framework but slim it down to the
> bare essential
> * move the "exampleext" component to specialpurpose and migrate to it all
> the extra features: this could also be used as a best practice guide on how
> to extend a component from hot-deploy/specialpurpose
>
> I still think that it would be nicer to not bundle the "example" component
> ootb to keep the framework cleaner: the example should be downloaded
> separately (when we will have clear separation between framework and the
> rest); this approach is similar to tomcat and its example applications. But
> I don't have a strong opinion on this.
>
> Jacopo
>
>

Re: Lose Weight Program for OFBiz - example, exampleext

[Anne <an...@cohsoft.com.au>]

Just wanted to mention an idea I had: add a new group "Examples" alongside
applications and specialpurpose and hot-deploy (maybe replacing
specialpurpose?).

It should be easy to enable/disable the entire group in one go. So new
developers have it easily available, it is easy to enable for demos, and
easy to disable for production.

It could have multiple components, rather than just example and exampleext.
Each component could showcase best practice for a particular function. For
example, there could be one component for Ajax widgets, and one for
Jackrabbit, and so on. I think individual example components would be
easier to maintain than one or two large ones.

Projects in Extras could include a sample component that gets installed in
Examples, showing example code using that Extra.

Having support for Extras examples in core might encourage Extras
developers to provide good sample code.

Cheers,
Anne.

On 22 March 2012 04:36, Olivier Heintz <ho...@nereide.biz> wrote:

> Le 20/03/2012 23:44, Jacques Le Roux a écrit :
>
>  From: "Mansour Al Akeel" <ma...@gmail.com>
>>
>>> Everyone has different preference about how would the basic component
>>> skeleton looks like (ie, with ajax, without, exta functionality ....
>>> ).
>>> Even if a basic example included with ofbiz distribution, in the
>>> future it will grow again with extra unneeded functionality, or it
>>> will be an on going discussion about what should go there.
>>>
>>> It's much easier to provide a very basic skeleton as a separate
>>> download, to serve as an example and a reference. There could be more
>>> than one example provided, each showing different capabilities and
>>> different techniques. This is better than creating one huge example to
>>> show everything, and better than showing only the basics without any
>>> additional tips (ie, ajax).
>>>
>> +1 for additional download for a example (or exempleext) showing all the
> current development best practice. This component could be update by a
> other plug-in which install a extra functionality to showing how to use it.
>
>
>>> Those who are not satisfied with the examples as a skeleton, can
>>> maintain their own copy that will make him/her start a component
>>> quickly.
>>>
>>> Examples are not needed to run ofbiz.
>>>
>>
>> So they (examples and examplesext) could be in specialpurpose (+1) of
>> even Extras (0)
>>
>> Jacques
>>
>>
>>> On Tue, Mar 20, 2012 at 4:33 PM, Erwan de FERRIERES
>>> <erwan.de-ferrieres@nereide.fr**> wrote:
>>>
>>>> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>>>
>>>>>
>>>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>>>>
>>>>>
>>>>>
>>>>> Adrian would like to keep Example in the framework but slim it down a
>>>>> lot
>>>>> to the essential (no form widgets examples, no Ajax examples, no
>>>>> content
>>>>> examples etc...). Adrian would you please confirm if in your vision the
>>>>> "example" application should document the layout of a typical OFBiz
>>>>> component only? If yes, we could use the output of the "ant
>>>>> create-component" task to document the best practice layout.
>>>>> Jacques, Olivier would like to keep also the examples for the various
>>>>> higher level features available to OFBiz applications.
>>>>>
>>>>> I think that from the discussion it could emerge the following
>>>>> solution to
>>>>> please everyone:
>>>>>
>>>>> * keep the "example" component in the framework but slim it down to the
>>>>> bare essential
>>>>> * move the "exampleext" component to specialpurpose and migrate to it
>>>>> all
>>>>> the extra features: this could also be used as a best practice guide
>>>>> on how
>>>>> to extend a component from hot-deploy/specialpurpose
>>>>>
>>>>> I still think that it would be nicer to not bundle the "example"
>>>>> component
>>>>> ootb to keep the framework cleaner: the example should be downloaded
>>>>> separately (when we will have clear separation between framework and
>>>>> the
>>>>> rest); this approach is similar to tomcat and its example
>>>>> applications. But
>>>>> I don't have a strong opinion on this.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>>  create 2 components, one basic with simple CRUD and no ajax or
>>>> whatever, and
>>>> another one with more eye candy stuff (ajax, modal forms, etc...). Both
>>>> components should be in specialpurpose/
>>>> I'm not in favor of moving them to extras, as when delivering an
>>>> official
>>>> release there should be a showcase included. And as Adrian said, when
>>>> teaching people how to create apps with OFBiz, this could be really
>>>> useful.
>>>> And with JSR-223, there's a lot to add !
>>>>
>>>> --
>>>> 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: sales@cohsoft.com.au

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

Re: Lose Weight Program for OFBiz - example, exampleext

[Olivier Heintz <ho...@nereide.biz>]

Le 20/03/2012 23:44, Jacques Le Roux a écrit :
> From: "Mansour Al Akeel" <ma...@gmail.com>
>> Everyone has different preference about how would the basic component
>> skeleton looks like (ie, with ajax, without, exta functionality ....
>> ).
>> Even if a basic example included with ofbiz distribution, in the
>> future it will grow again with extra unneeded functionality, or it
>> will be an on going discussion about what should go there.
>>
>> It's much easier to provide a very basic skeleton as a separate
>> download, to serve as an example and a reference. There could be more
>> than one example provided, each showing different capabilities and
>> different techniques. This is better than creating one huge example to
>> show everything, and better than showing only the basics without any
>> additional tips (ie, ajax).
+1 for additional download for a example (or exempleext) showing all the 
current development best practice. This component could be update by a 
other plug-in which install a extra functionality to showing how to use it.
>>
>> Those who are not satisfied with the examples as a skeleton, can
>> maintain their own copy that will make him/her start a component
>> quickly.
>>
>> Examples are not needed to run ofbiz.
>
> So they (examples and examplesext) could be in specialpurpose (+1) of 
> even Extras (0)
>
> Jacques
>
>>
>> On Tue, Mar 20, 2012 at 4:33 PM, Erwan de FERRIERES
>> <er...@nereide.fr> wrote:
>>> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>>>>
>>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>>
>>>>
>>>> Adrian would like to keep Example in the framework but slim it down 
>>>> a lot
>>>> to the essential (no form widgets examples, no Ajax examples, no 
>>>> content
>>>> examples etc...). Adrian would you please confirm if in your vision 
>>>> the
>>>> "example" application should document the layout of a typical OFBiz
>>>> component only? If yes, we could use the output of the "ant
>>>> create-component" task to document the best practice layout.
>>>> Jacques, Olivier would like to keep also the examples for the various
>>>> higher level features available to OFBiz applications.
>>>>
>>>> I think that from the discussion it could emerge the following 
>>>> solution to
>>>> please everyone:
>>>>
>>>> * keep the "example" component in the framework but slim it down to 
>>>> the
>>>> bare essential
>>>> * move the "exampleext" component to specialpurpose and migrate to 
>>>> it all
>>>> the extra features: this could also be used as a best practice 
>>>> guide on how
>>>> to extend a component from hot-deploy/specialpurpose
>>>>
>>>> I still think that it would be nicer to not bundle the "example" 
>>>> component
>>>> ootb to keep the framework cleaner: the example should be downloaded
>>>> separately (when we will have clear separation between framework 
>>>> and the
>>>> rest); this approach is similar to tomcat and its example 
>>>> applications. But
>>>> I don't have a strong opinion on this.
>>>>
>>>> Jacopo
>>>>
>>>>
>>> create 2 components, one basic with simple CRUD and no ajax or 
>>> whatever, and
>>> another one with more eye candy stuff (ajax, modal forms, etc...). Both
>>> components should be in specialpurpose/
>>> I'm not in favor of moving them to extras, as when delivering an 
>>> official
>>> release there should be a showcase included. And as Adrian said, when
>>> teaching people how to create apps with OFBiz, this could be really 
>>> useful.
>>> And with JSR-223, there's a lot to add !
>>>
>>> -- 
>>> Erwan de FERRIERES
>>> www.nereide.biz
>>
>

Re: Lose Weight Program for OFBiz - example, exampleext

[Divesh Dutta <di...@hotwaxmedia.com>]

My +1 for moving them to Extras. Reason is, if we need to keep it for  best practice guide or for training then no doubt its a extra work.  We can give good documentation with details about how to use /extras/example component to learn and keep it as best practice guide. Also we can promote this in user mailing lists .

Thanks
--
Divesh

On Mar 21, 2012, at 4:14 AM, Jacques Le Roux wrote:

> From: "Mansour Al Akeel" <ma...@gmail.com>
>> Everyone has different preference about how would the basic component
>> skeleton looks like (ie, with ajax, without, exta functionality ....
>> ).
>> Even if a basic example included with ofbiz distribution, in the
>> future it will grow again with extra unneeded functionality, or it
>> will be an on going discussion about what should go there.
>> 
>> It's much easier to provide a very basic skeleton as a separate
>> download, to serve as an example and a reference. There could be more
>> than one example provided, each showing different capabilities and
>> different techniques. This is better than creating one huge example to
>> show everything, and better than showing only the basics without any
>> additional tips (ie, ajax).
>> 
>> Those who are not satisfied with the examples as a skeleton, can
>> maintain their own copy that will make him/her start a component
>> quickly.
>> 
>> Examples are not needed to run ofbiz.
> 
> So they (examples and examplesext) could be in specialpurpose (+1) of even Extras (0)
> 
> Jacques
> 
>> 
>> On Tue, Mar 20, 2012 at 4:33 PM, Erwan de FERRIERES
>> <er...@nereide.fr> wrote:
>>> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>>>> 
>>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>> 
>>>> 
>>>> Adrian would like to keep Example in the framework but slim it down a lot
>>>> to the essential (no form widgets examples, no Ajax examples, no content
>>>> examples etc...). Adrian would you please confirm if in your vision the
>>>> "example" application should document the layout of a typical OFBiz
>>>> component only? If yes, we could use the output of the "ant
>>>> create-component" task to document the best practice layout.
>>>> Jacques, Olivier would like to keep also the examples for the various
>>>> higher level features available to OFBiz applications.
>>>> 
>>>> I think that from the discussion it could emerge the following solution to
>>>> please everyone:
>>>> 
>>>> * keep the "example" component in the framework but slim it down to the
>>>> bare essential
>>>> * move the "exampleext" component to specialpurpose and migrate to it all
>>>> the extra features: this could also be used as a best practice guide on how
>>>> to extend a component from hot-deploy/specialpurpose
>>>> 
>>>> I still think that it would be nicer to not bundle the "example" component
>>>> ootb to keep the framework cleaner: the example should be downloaded
>>>> separately (when we will have clear separation between framework and the
>>>> rest); this approach is similar to tomcat and its example applications. But
>>>> I don't have a strong opinion on this.
>>>> 
>>>> Jacopo
>>>> 
>>>> 
>>> create 2 components, one basic with simple CRUD and no ajax or whatever, and
>>> another one with more eye candy stuff (ajax, modal forms, etc...). Both
>>> components should be in specialpurpose/
>>> I'm not in favor of moving them to extras, as when delivering an official
>>> release there should be a showcase included. And as Adrian said, when
>>> teaching people how to create apps with OFBiz, this could be really useful.
>>> And with JSR-223, there's a lot to add !
>>> 
>>> --
>>> Erwan de FERRIERES
>>> www.nereide.biz

Re: Lose Weight Program for OFBiz - example, exampleext

[Jacques Le Roux <ja...@les7arts.com>]

From: "Mansour Al Akeel" <ma...@gmail.com>
> Everyone has different preference about how would the basic component
> skeleton looks like (ie, with ajax, without, exta functionality ....
> ).
> Even if a basic example included with ofbiz distribution, in the
> future it will grow again with extra unneeded functionality, or it
> will be an on going discussion about what should go there.
>
> It's much easier to provide a very basic skeleton as a separate
> download, to serve as an example and a reference. There could be more
> than one example provided, each showing different capabilities and
> different techniques. This is better than creating one huge example to
> show everything, and better than showing only the basics without any
> additional tips (ie, ajax).
>
> Those who are not satisfied with the examples as a skeleton, can
> maintain their own copy that will make him/her start a component
> quickly.
>
> Examples are not needed to run ofbiz.

So they (examples and examplesext) could be in specialpurpose (+1) of even Extras (0)

Jacques

>
> On Tue, Mar 20, 2012 at 4:33 PM, Erwan de FERRIERES
> <er...@nereide.fr> wrote:
>> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>>>
>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>
>>>
>>> Adrian would like to keep Example in the framework but slim it down a lot
>>> to the essential (no form widgets examples, no Ajax examples, no content
>>> examples etc...). Adrian would you please confirm if in your vision the
>>> "example" application should document the layout of a typical OFBiz
>>> component only? If yes, we could use the output of the "ant
>>> create-component" task to document the best practice layout.
>>> Jacques, Olivier would like to keep also the examples for the various
>>> higher level features available to OFBiz applications.
>>>
>>> I think that from the discussion it could emerge the following solution to
>>> please everyone:
>>>
>>> * keep the "example" component in the framework but slim it down to the
>>> bare essential
>>> * move the "exampleext" component to specialpurpose and migrate to it all
>>> the extra features: this could also be used as a best practice guide on how
>>> to extend a component from hot-deploy/specialpurpose
>>>
>>> I still think that it would be nicer to not bundle the "example" component
>>> ootb to keep the framework cleaner: the example should be downloaded
>>> separately (when we will have clear separation between framework and the
>>> rest); this approach is similar to tomcat and its example applications. But
>>> I don't have a strong opinion on this.
>>>
>>> Jacopo
>>>
>>>
>> create 2 components, one basic with simple CRUD and no ajax or whatever, and
>> another one with more eye candy stuff (ajax, modal forms, etc...). Both
>> components should be in specialpurpose/
>> I'm not in favor of moving them to extras, as when delivering an official
>> release there should be a showcase included. And as Adrian said, when
>> teaching people how to create apps with OFBiz, this could be really useful.
>> And with JSR-223, there's a lot to add !
>>
>> --
>> Erwan de FERRIERES
>> www.nereide.biz
> 

Re: Lose Weight Program for OFBiz - example, exampleext

[Mansour Al Akeel <ma...@gmail.com>]

Everyone has different preference about how would the basic component
skeleton looks like (ie, with ajax, without, exta functionality ....
).
Even if a basic example included with ofbiz distribution, in the
future it will grow again with extra unneeded functionality, or it
will be an on going discussion about what should go there.

It's much easier to provide a very basic skeleton as a separate
download, to serve as an example and a reference. There could be more
than one example provided, each showing different capabilities and
different techniques. This is better than creating one huge example to
show everything, and better than showing only the basics without any
additional tips (ie, ajax).

Those who are not satisfied with the examples as a skeleton, can
maintain their own copy that will make him/her start a component
quickly.

Examples are not needed to run ofbiz.


On Tue, Mar 20, 2012 at 4:33 PM, Erwan de FERRIERES
<er...@nereide.fr> wrote:
> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>>
>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>
>>
>> Adrian would like to keep Example in the framework but slim it down a lot
>> to the essential (no form widgets examples, no Ajax examples, no content
>> examples etc...). Adrian would you please confirm if in your vision the
>> "example" application should document the layout of a typical OFBiz
>> component only? If yes, we could use the output of the "ant
>> create-component" task to document the best practice layout.
>> Jacques, Olivier would like to keep also the examples for the various
>> higher level features available to OFBiz applications.
>>
>> I think that from the discussion it could emerge the following solution to
>> please everyone:
>>
>> * keep the "example" component in the framework but slim it down to the
>> bare essential
>> * move the "exampleext" component to specialpurpose and migrate to it all
>> the extra features: this could also be used as a best practice guide on how
>> to extend a component from hot-deploy/specialpurpose
>>
>> I still think that it would be nicer to not bundle the "example" component
>> ootb to keep the framework cleaner: the example should be downloaded
>> separately (when we will have clear separation between framework and the
>> rest); this approach is similar to tomcat and its example applications. But
>> I don't have a strong opinion on this.
>>
>> Jacopo
>>
>>
> create 2 components, one basic with simple CRUD and no ajax or whatever, and
> another one with more eye candy stuff (ajax, modal forms, etc...). Both
> components should be in specialpurpose/
> I'm not in favor of moving them to extras, as when delivering an official
> release there should be a showcase included. And as Adrian said, when
> teaching people how to create apps with OFBiz, this could be really useful.
> And with JSR-223, there's a lot to add !
>
> --
> Erwan de FERRIERES
> www.nereide.biz

Re: Lose Weight Program for OFBiz - example, exampleext

[Erwan de FERRIERES <er...@nereide.fr>]

Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>> Q) framework/example and framework/exampleext: move to specialpurpose
>
> Adrian would like to keep Example in the framework but slim it down a lot to the essential (no form widgets examples, no Ajax examples, no content examples etc...). Adrian would you please confirm if in your vision the "example" application should document the layout of a typical OFBiz component only? If yes, we could use the output of the "ant create-component" task to document the best practice layout.
> Jacques, Olivier would like to keep also the examples for the various higher level features available to OFBiz applications.
>
> I think that from the discussion it could emerge the following solution to please everyone:
>
> * keep the "example" component in the framework but slim it down to the bare essential
> * move the "exampleext" component to specialpurpose and migrate to it all the extra features: this could also be used as a best practice guide on how to extend a component from hot-deploy/specialpurpose
>
> I still think that it would be nicer to not bundle the "example" component ootb to keep the framework cleaner: the example should be downloaded separately (when we will have clear separation between framework and the rest); this approach is similar to tomcat and its example applications. But I don't have a strong opinion on this.
>
> Jacopo
>
>
create 2 components, one basic with simple CRUD and no ajax or whatever, 
and another one with more eye candy stuff (ajax, modal forms, etc...). 
Both components should be in specialpurpose/
I'm not in favor of moving them to extras, as when delivering an 
official release there should be a showcase included. And as Adrian 
said, when teaching people how to create apps with OFBiz, this could be 
really useful. And with JSR-223, there's a lot to add !

-- 
Erwan de FERRIERES
www.nereide.biz

Lose Weight Program for OFBiz - example, exampleext

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

> Q) framework/example and framework/exampleext: move to specialpurpose

Adrian would like to keep Example in the framework but slim it down a lot to the essential (no form widgets examples, no Ajax examples, no content examples etc...). Adrian would you please confirm if in your vision the "example" application should document the layout of a typical OFBiz component only? If yes, we could use the output of the "ant create-component" task to document the best practice layout.
Jacques, Olivier would like to keep also the examples for the various higher level features available to OFBiz applications.

I think that from the discussion it could emerge the following solution to please everyone:

* keep the "example" component in the framework but slim it down to the bare essential
* move the "exampleext" component to specialpurpose and migrate to it all the extra features: this could also be used as a best practice guide on how to extend a component from hot-deploy/specialpurpose

I still think that it would be nicer to not bundle the "example" component ootb to keep the framework cleaner: the example should be downloaded separately (when we will have clear separation between framework and the rest); this approach is similar to tomcat and its example applications. But I don't have a strong opinion on this.

Jacopo

Re: Lose Weight Program for OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

The main purpose of this thread is discussing the ideas; then we can proceed with the plan where there is agreement, discuss more (as it is happening for the "example" component) and find a good solution; if there are different opinions on specific components, and we will not find a good solution for all, we could start a vote.
But I don't think it is necessary to vote formally on each specific item (but I am not against this idea if there is a general interest in a formal vote): we usually don't vote to add new features and in the same way we can remove them if there is a lazy consensus.

Kind regards,

Jacopo

On Mar 18, 2012, at 1:08 PM, Hans Bakker wrote:

> Jacopo,
> 
> seeing you are such a believer in community discussion, i assume this is a proposal which gets properly discussed and will be voted upon?
> 
> Regards,
> Hans
> 
> 
> On 03/18/2012 04:10 PM, Jacopo Cappellato wrote:
>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>> 
>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>> 
>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>> 
>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>> And this is exactly what we have now:
>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>> 
>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>> 
>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>> 
>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>> 
>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>> 
>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>> 
>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>> * is this feature used by other code in the system?
>> * is the feature functional? or is it largely incomplete?
>> * is this an old component/code?
>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>> 
>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>> 
>> 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"
>> 
>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>> 
>> 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"
>> 
>> C) $OFBIZ_HOME/debian: move to "Attic"
>> 
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>> 
>> E) specialpurpose/workflow: move to "Attic"
>> 
>> F) specialpurpose/shark: move to "Attic"
>> 
>> G) specialpurpose/ofbizwebsite: move to "Attic"
>> 
>> 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"
>> 
>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>> 
>> J) framework/appserver: move to "Extras"
>> 
>> K) framework/jetty: move to "Extras" (or "Attic")
>> 
>> 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"
>> 
>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>> 
>> O) framework/documents: move the content to Wiki and then move to "Attic"
>> 
>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>> 
>> Q) framework/example and framework/exampleext: move to specialpurpose
>> 
>> Kind regards,
>> 
>> Jacopo
>> 
> 

Re: Lose Weight Program for OFBiz

[Hans Bakker <ma...@antwebsystems.com>]

Jacopo,

seeing you are such a believer in community discussion, i assume this is 
a proposal which gets properly discussed and will be voted upon?

Regards,
Hans


On 03/18/2012 04:10 PM, Jacopo Cappellato wrote:
> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>
> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>
> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>
> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
> And this is exactly what we have now:
> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>
> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>
> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>
> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>
> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>
> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>
> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
> * is this feature used by other code in the system?
> * is the feature functional? or is it largely incomplete?
> * is this an old component/code?
> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>
> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>
> 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"
>
> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>
> 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"
>
> C) $OFBIZ_HOME/debian: move to "Attic"
>
> D) the seleniumxml code in framework/testtools: move to "Attic"
>
> E) specialpurpose/workflow: move to "Attic"
>
> F) specialpurpose/shark: move to "Attic"
>
> G) specialpurpose/ofbizwebsite: move to "Attic"
>
> 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"
>
> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>
> J) framework/appserver: move to "Extras"
>
> K) framework/jetty: move to "Extras" (or "Attic")
>
> 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"
>
> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>
> O) framework/documents: move the content to Wiki and then move to "Attic"
>
> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>
> Q) framework/example and framework/exampleext: move to specialpurpose
>
> Kind regards,
>
> Jacopo
>

Re: Lose Weight Program for OFBiz - themes

[Ruth Hoffman <rh...@aesolves.com>]

Another data point: I've been in several OFBiz shops recently and have 
observed that many people end up using Flat Grey. Not sure why this is.

IMHO Tomahawk looks nice, but in the end, the mixture of dark and light 
is hard on the eyes. Having to scroll over to expose links makes 
navigation more cumbersome. The hierarchical features are really nice, 
but if you have to hunt around to find them, it diminishes their appeal. 
This is just my opinion and the reason I always end up using Flat Grey.

Best Regards,
Ruth Hoffman
On 3/20/12 12:36 PM, Anil Patel wrote:
> I prefer keep Flat Gray theme in Ofbiz over others.
>
> Thanks and Regards
> Anil Patel
>
> On Mar 20, 2012, at 9:18 AM, Jacques Le Roux wrote:
>
>> From: "Mansour Al Akeel"<ma...@gmail.com>
>>> Flat Gray is simple, and clear.
>>> It serves well as a basic theme.
>>> AFAIK, it the only theme that supports both directions for languages
>>> LTR and RTL.
>> Right and Tomahawk is the last evolution of all others. I prefer Tomahawk: it's easier to find you way because of hierarchised menus (with only 2 levels).
>> Flat Gray is a must have because of LTR and RTL (thanks Adrian!)
>>
>> One project for all themes in Extra makes sense to me.
>> Some/all? (all but Bizzness are pre-evolutions of Tomahawk) could go in Attic (I never got to use Bizzness), to be voted...
>>
>> Jacques
>>
>>> On Tue, Mar 20, 2012 at 10:33 AM,<ad...@sandglass-software.com>  wrote:
>>>> My preference is to keep Flat Grey and one other theme - I have no
>>>> preference on what that other theme is.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> Quoting Jacopo Cappellato<ja...@hotwaxmedia.com>:
>>>>
>>>>>> 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.
>>>>>
>>>>> Jacopo
>>>>
>>>>
>

Re: Lose Weight Program for OFBiz - themes

[Anil Patel <an...@hotwaxmedia.com>]

I prefer keep Flat Gray theme in Ofbiz over others. 

Thanks and Regards
Anil Patel

On Mar 20, 2012, at 9:18 AM, Jacques Le Roux wrote:

> From: "Mansour Al Akeel" <ma...@gmail.com>
>> Flat Gray is simple, and clear.
>> It serves well as a basic theme.
>> AFAIK, it the only theme that supports both directions for languages
>> LTR and RTL.
> 
> Right and Tomahawk is the last evolution of all others. I prefer Tomahawk: it's easier to find you way because of hierarchised menus (with only 2 levels).
> Flat Gray is a must have because of LTR and RTL (thanks Adrian!)
> 
> One project for all themes in Extra makes sense to me.
> Some/all? (all but Bizzness are pre-evolutions of Tomahawk) could go in Attic (I never got to use Bizzness), to be voted...
> 
> Jacques
> 
>> 
>> On Tue, Mar 20, 2012 at 10:33 AM,  <ad...@sandglass-software.com> wrote:
>>> My preference is to keep Flat Grey and one other theme - I have no
>>> preference on what that other theme is.
>>> 
>>> -Adrian
>>> 
>>> 
>>> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:
>>> 
>>>>> 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.
>>>> 
>>>> Jacopo
>>> 
>>> 
>>> 

Re: Lose Weight Program for OFBiz - themes

[Jacques Le Roux <ja...@les7arts.com>]

From: "Mansour Al Akeel" <ma...@gmail.com>
> Flat Gray is simple, and clear.
> It serves well as a basic theme.
> AFAIK, it the only theme that supports both directions for languages
> LTR and RTL.

Right and Tomahawk is the last evolution of all others. I prefer Tomahawk: it's easier to find you way because of hierarchised menus 
(with only 2 levels).
Flat Gray is a must have because of LTR and RTL (thanks Adrian!)

One project for all themes in Extra makes sense to me.
Some/all? (all but Bizzness are pre-evolutions of Tomahawk) could go in Attic (I never got to use Bizzness), to be voted...

Jacques

>
> On Tue, Mar 20, 2012 at 10:33 AM,  <ad...@sandglass-software.com> wrote:
>> My preference is to keep Flat Grey and one other theme - I have no
>> preference on what that other theme is.
>>
>> -Adrian
>>
>>
>> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:
>>
>>>> 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.
>>>
>>> Jacopo
>>
>>
>>
>> 

Re: Lose Weight Program for OFBiz - themes

[Mansour Al Akeel <ma...@gmail.com>]

Flat Gray is simple, and clear.
It serves well as a basic theme.
AFAIK, it the only theme that supports both directions for languages
LTR and RTL.


On Tue, Mar 20, 2012 at 10:33 AM,  <ad...@sandglass-software.com> wrote:
> My preference is to keep Flat Grey and one other theme - I have no
> preference on what that other theme is.
>
> -Adrian
>
>
> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:
>
>>> 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.
>>
>> Jacopo
>
>
>
>

Re: Lose Weight Program for OFBiz - themes

[ad...@sandglass-software.com]

My preference is to keep Flat Grey and one other theme - I have no  
preference on what that other theme is.

-Adrian

Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:

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

Re: Lose Weight Program for OFBiz - themes

[Jacques Le Roux <ja...@les7arts.com>]

From: "Mansour Al Akeel" <ma...@gmail.com>
> Jacques,
> 
> inline:
> 
> 
> On Wed, Mar 21, 2012 at 2:07 AM, Jacques Le Roux
> <ja...@les7arts.com> wrote:
>> Hi Mansour,
>>
>>
>> From: "Mansour Al Akeel" <ma...@gmail.com>
>>>
>>> Jacques,
>>>
>>> We use RTL.
>>> May be you are right about the the ease of use to find an item, but
>>> the user who has permission to all these functionality is an admin,
>>> and normally, she is comfortable finding any item quickly. The rest of
>>> the uses don't have that much items and menus shown.
>>
>>
>> This makes sense for a deployment, not OOTB. It's IMO easier to select Flat
>> Grey, if you prefer, for your deployments and to keep
>> Tomahawk as OOTB default for the reasons I explained and others I add below.
>>
> 
> Yes, this will work. So you are offering a fancier theme for the demo
> purposes, targeting new comers,
> and developers, can make a copy of FlatGray and customize it. Sound good.
> 
>>
>>> I know, other themes may look better, or fancier, but most users use
>>> flat gray to base their work on and extend/customize it, because it's
>>> easier and cleaner. I am not sure if bigger organization prefer
>>> fancier look and feel over cleaner. And to be honest, I think flat
>>> gray looks more professional than others. Therefore, it give a
>>> positive first impression, when demonstrated.
>>>
>>> Additional themes may still exist beside FlatGray, but I recommend to
>>> make it the default one.
>>
>>
>> What makes you think "most users use flat gray to base their work" ?
> 
> Sorry, I didn't express it properly. I meant most user based on my
> experience. I have two developers, I worked with,
> extend flat gray, and customize it as they need. This is not a number
> that can be a base for a statistical study,
> and generalize it. It's only my limited experience. Sorry for the confusion.
> 
>> Could you define "easier and cleaner", and why Flat Grey is easier and
>> cleaner (besides that it's the only one that is RTL which I
>> understand for you is a must have)
> 
> Cleaner and easier in terms of usage:
> The menu is at the top, showing all the available item, makes it easy
> to see what I need in case I navigated to the wrong section, or need
> another
> section. Nothing hidden. In fact even as a demo, it has some positive effect.
> 
> and Cleaner and easier in terms of development:
> Flat Gray code is not cluttered. (that is how I feel).
> 
>> What makes you think Flat Grey looks more professionnal? For me Flat Gray
>> has not enough contrast. In other words all looks
>> grey/pale and it's difficult to spot things.
> 
> I work more with enterprise portals than with ERPs. From what I have
> seen, portal severs default theme is mostly light,
> with darker high light. And I find FlatGray closer to them than
> Tomahawk theme is.
> 
> For example:
> http://portals.apache.org/jetspeed-2/
> and:
> http://www.liferay.com/products/liferay-portal/overview
> 
> After all, It is not that hard for a developer to change the style of
> OFBiz themes to reflect the colors she likes.
> 
>> With Tomahawk I quickly spot buttons, links, etc. because there is more
>> contrast. Maybe it's
>> If you read me, it's not about being fancier but ergonomic which is for me
>> the only priority for the community to use OFBiz OOTB
>> (contrary to deployments)
> 
> It's the opposite to me. I find it easier to spot things using
> FlatGray. But again not a big deal.
> 
>>
>> Also I'd like to know why Flat Grey is the only Theme being marked as being
>> Sight-Impaired Accessible? Adrian? I remember I began to
>> add <<title="Skip navigation" accesskey="2>> (which is really only a
>> small/poor beginnng) but that's for all themes. What is
>> specific to Flat Grey?
>>
> 
>> The only things I could concede:
>> 1. Like 1 to 5% of the male population (women are rarely touched) I'm
>> daltonian (kind of sight-impaired ;o) so my vision about
>> contrast is maybe biased
>> 2. Maybe, because it uses a blackboard background style rather than a white
>> paper style, Tomahawk is more arduous for eyes on a long
>> term (hours of work)
> 
> Yes. I can see this, and I agree.
> 
>>
>> Thanks for sharing your opinion :o)
>>
>> Jacques
>>
> 
> Finally, it's a personal preference.
> However, I like to keep FlatGray. Doesn't have to be the default,
> Unless demos in RTL needed.

That's an important point, and makes me need to consider indeed! 
I mean it's not obvious for new comers that only one theme is RTL able
I think it should be default because of that, and keep Tomahawk as OOTB alternative 

Jacques


> Thank you.
> 
>>
>>>
>>> On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux
>>> <ja...@les7arts.com> wrote:
>>>>
>>>> I see that most people prefer Flat Grey.
>>>>
>>>> Let me explain why I prefer Tomahawk.
>>>>
>>>> Did you ever wonder why the paper we write on has more than often a
>>>> greater
>>>> height than width, why newspaper have many columns, etc.
>>>> Here is an answer
>>>>
>>>> http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns
>>>>
>>>> OK, my argument: don't you feel a pain to find an application, a menu
>>>> entry
>>>> in Flat Grey? No? Then you are used to find it at some place and don't
>>>> care
>>>> anymore. Now just imagine the same for a new user...
>>>>
>>>> This is where Tomahawk is better. It's far easier to find an entry in 2
>>>> colums (applications in Tomahawk) than in 7 columns (applications in Flat
>>>> Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in
>>>> Flat Grey). Just try it
>>>>
>>>> Another point: Product screens are awful in Flat Grey (to many buttons
>>>> for
>>>> menus, hard to spot). Though actually I believe Tomahawk would benefit
>>>> from
>>>> a third column, for instance for Product. This could be 2 twin columns if
>>>> more than, say, 15 entries would show in a column. Like we have for
>>>> Applications, though not sure how it's organized. I mean why some are in
>>>> right column and other in left one? Also something wich could help spot
>>>> entries quicker would be to allow sorting entries in menus by language.
>>>> It's
>>>> now only done based on English.
>>>>
>>>> OK, now there is the RTL feature. Who use it? Few I guess
>>>> (http://en.wikipedia.org/wiki/Right-to-left
>>>> http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does
>>>> not
>>>> diminish RTL importance, but ponders it in choice for a default theme.
>>>>
>>>> My 2 cts
>>>>
>>>> Jacques
>>>>
>>>>
>>>> From: "Ashish Vijaywargiya" <vi...@gmail.com>
>>>>
>>>>> My vote will be to keep two themes in the project. IMO Flatgrey theme is
>>>>> the best to keep as the default one for the project.
>>>>>
>>>>> --
>>>>> Ashish
>>>>>
>>>>> On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato <
>>>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>>>
>>>>>> Jacopo
>>>>>
>>>>>
>>>>>
>>>>
>>

Re: Lose Weight Program for OFBiz - themes

[Mansour Al Akeel <ma...@gmail.com>]

Jacques,

inline:


On Wed, Mar 21, 2012 at 2:07 AM, Jacques Le Roux
<ja...@les7arts.com> wrote:
> Hi Mansour,
>
>
> From: "Mansour Al Akeel" <ma...@gmail.com>
>>
>> Jacques,
>>
>> We use RTL.
>> May be you are right about the the ease of use to find an item, but
>> the user who has permission to all these functionality is an admin,
>> and normally, she is comfortable finding any item quickly. The rest of
>> the uses don't have that much items and menus shown.
>
>
> This makes sense for a deployment, not OOTB. It's IMO easier to select Flat
> Grey, if you prefer, for your deployments and to keep
> Tomahawk as OOTB default for the reasons I explained and others I add below.
>

Yes, this will work. So you are offering a fancier theme for the demo
purposes, targeting new comers,
and developers, can make a copy of FlatGray and customize it. Sound good.

>
>> I know, other themes may look better, or fancier, but most users use
>> flat gray to base their work on and extend/customize it, because it's
>> easier and cleaner. I am not sure if bigger organization prefer
>> fancier look and feel over cleaner. And to be honest, I think flat
>> gray looks more professional than others. Therefore, it give a
>> positive first impression, when demonstrated.
>>
>> Additional themes may still exist beside FlatGray, but I recommend to
>> make it the default one.
>
>
> What makes you think "most users use flat gray to base their work" ?

Sorry, I didn't express it properly. I meant most user based on my
experience. I have two developers, I worked with,
extend flat gray, and customize it as they need. This is not a number
that can be a base for a statistical study,
and generalize it. It's only my limited experience. Sorry for the confusion.

> Could you define "easier and cleaner", and why Flat Grey is easier and
> cleaner (besides that it's the only one that is RTL which I
> understand for you is a must have)

Cleaner and easier in terms of usage:
The menu is at the top, showing all the available item, makes it easy
to see what I need in case I navigated to the wrong section, or need
another
section. Nothing hidden. In fact even as a demo, it has some positive effect.

and Cleaner and easier in terms of development:
Flat Gray code is not cluttered. (that is how I feel).

> What makes you think Flat Grey looks more professionnal? For me Flat Gray
> has not enough contrast. In other words all looks
> grey/pale and it's difficult to spot things.

I work more with enterprise portals than with ERPs. From what I have
seen, portal severs default theme is mostly light,
with darker high light. And I find FlatGray closer to them than
Tomahawk theme is.

For example:
http://portals.apache.org/jetspeed-2/
and:
http://www.liferay.com/products/liferay-portal/overview

After all, It is not that hard for a developer to change the style of
OFBiz themes to reflect the colors she likes.

> With Tomahawk I quickly spot buttons, links, etc. because there is more
> contrast. Maybe it's
> If you read me, it's not about being fancier but ergonomic which is for me
> the only priority for the community to use OFBiz OOTB
> (contrary to deployments)

It's the opposite to me. I find it easier to spot things using
FlatGray. But again not a big deal.

>
> Also I'd like to know why Flat Grey is the only Theme being marked as being
> Sight-Impaired Accessible? Adrian? I remember I began to
> add <<title="Skip navigation" accesskey="2>> (which is really only a
> small/poor beginnng) but that's for all themes. What is
> specific to Flat Grey?
>

> The only things I could concede:
> 1. Like 1 to 5% of the male population (women are rarely touched) I'm
> daltonian (kind of sight-impaired ;o) so my vision about
> contrast is maybe biased
> 2. Maybe, because it uses a blackboard background style rather than a white
> paper style, Tomahawk is more arduous for eyes on a long
> term (hours of work)

Yes. I can see this, and I agree.

>
> Thanks for sharing your opinion :o)
>
> Jacques
>

Finally, it's a personal preference.
However, I like to keep FlatGray. Doesn't have to be the default,
Unless demos in RTL needed.

Thank you.

>
>>
>> On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux
>> <ja...@les7arts.com> wrote:
>>>
>>> I see that most people prefer Flat Grey.
>>>
>>> Let me explain why I prefer Tomahawk.
>>>
>>> Did you ever wonder why the paper we write on has more than often a
>>> greater
>>> height than width, why newspaper have many columns, etc.
>>> Here is an answer
>>>
>>> http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns
>>>
>>> OK, my argument: don't you feel a pain to find an application, a menu
>>> entry
>>> in Flat Grey? No? Then you are used to find it at some place and don't
>>> care
>>> anymore. Now just imagine the same for a new user...
>>>
>>> This is where Tomahawk is better. It's far easier to find an entry in 2
>>> colums (applications in Tomahawk) than in 7 columns (applications in Flat
>>> Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in
>>> Flat Grey). Just try it
>>>
>>> Another point: Product screens are awful in Flat Grey (to many buttons
>>> for
>>> menus, hard to spot). Though actually I believe Tomahawk would benefit
>>> from
>>> a third column, for instance for Product. This could be 2 twin columns if
>>> more than, say, 15 entries would show in a column. Like we have for
>>> Applications, though not sure how it's organized. I mean why some are in
>>> right column and other in left one? Also something wich could help spot
>>> entries quicker would be to allow sorting entries in menus by language.
>>> It's
>>> now only done based on English.
>>>
>>> OK, now there is the RTL feature. Who use it? Few I guess
>>> (http://en.wikipedia.org/wiki/Right-to-left
>>> http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does
>>> not
>>> diminish RTL importance, but ponders it in choice for a default theme.
>>>
>>> My 2 cts
>>>
>>> Jacques
>>>
>>>
>>> From: "Ashish Vijaywargiya" <vi...@gmail.com>
>>>
>>>> My vote will be to keep two themes in the project. IMO Flatgrey theme is
>>>> the best to keep as the default one for the project.
>>>>
>>>> --
>>>> Ashish
>>>>
>>>> On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato <
>>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>>
>>>>> Jacopo
>>>>
>>>>
>>>>
>>>
>

Re: Lose Weight Program for OFBiz - themes

[Jacques Le Roux <ja...@les7arts.com>]

Hi Mansour,

From: "Mansour Al Akeel" <ma...@gmail.com>
> Jacques,
> We use RTL.
> May be you are right about the the ease of use to find an item, but
> the user who has permission to all these functionality is an admin,
> and normally, she is comfortable finding any item quickly. The rest of
> the uses don't have that much items and menus shown.

This makes sense for a deployment, not OOTB. It's IMO easier to select Flat Grey, if you prefer, for your deployments and to keep
Tomahawk as OOTB default for the reasons I explained and others I add below.

> I know, other themes may look better, or fancier, but most users use
> flat gray to base their work on and extend/customize it, because it's
> easier and cleaner. I am not sure if bigger organization prefer
> fancier look and feel over cleaner. And to be honest, I think flat
> gray looks more professional than others. Therefore, it give a
> positive first impression, when demonstrated.
>
> Additional themes may still exist beside FlatGray, but I recommend to
> make it the default one.

What makes you think "most users use flat gray to base their work" ?
Could you define "easier and cleaner", and why Flat Grey is easier and cleaner (besides that it's the only one that is RTL which I
understand for you is a must have)
What makes you think Flat Grey looks more professionnal? For me Flat Gray has not enough contrast. In other words all looks
grey/pale and it's difficult to spot things.
With Tomahawk I quickly spot buttons, links, etc. because there is more contrast. Maybe it's
If you read me, it's not about being fancier but ergonomic which is for me the only priority for the community to use OFBiz OOTB
(contrary to deployments)

Also I'd like to know why Flat Grey is the only Theme being marked as being Sight-Impaired Accessible? Adrian? I remember I began to
add <<title="Skip navigation" accesskey="2>> (which is really only a small/poor beginnng) but that's for all themes. What is
specific to Flat Grey?

The only things I could concede:
1. Like 1 to 5% of the male population (women are rarely touched) I'm daltonian (kind of sight-impaired ;o) so my vision about
contrast is maybe biased
2. Maybe, because it uses a blackboard background style rather than a white paper style, Tomahawk is more arduous for eyes on a long
term (hours of work)

Thanks for sharing your opinion :o)

Jacques

>
> On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux
> <ja...@les7arts.com> wrote:
>> I see that most people prefer Flat Grey.
>>
>> Let me explain why I prefer Tomahawk.
>>
>> Did you ever wonder why the paper we write on has more than often a greater
>> height than width, why newspaper have many columns, etc.
>> Here is an answer
>> http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns
>>
>> OK, my argument: don't you feel a pain to find an application, a menu entry
>> in Flat Grey? No? Then you are used to find it at some place and don't care
>> anymore. Now just imagine the same for a new user...
>>
>> This is where Tomahawk is better. It's far easier to find an entry in 2
>> colums (applications in Tomahawk) than in 7 columns (applications in Flat
>> Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in
>> Flat Grey). Just try it
>>
>> Another point: Product screens are awful in Flat Grey (to many buttons for
>> menus, hard to spot). Though actually I believe Tomahawk would benefit from
>> a third column, for instance for Product. This could be 2 twin columns if
>> more than, say, 15 entries would show in a column. Like we have for
>> Applications, though not sure how it's organized. I mean why some are in
>> right column and other in left one? Also something wich could help spot
>> entries quicker would be to allow sorting entries in menus by language. It's
>> now only done based on English.
>>
>> OK, now there is the RTL feature. Who use it? Few I guess
>> (http://en.wikipedia.org/wiki/Right-to-left
>> http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does not
>> diminish RTL importance, but ponders it in choice for a default theme.
>>
>> My 2 cts
>>
>> Jacques
>>
>>
>> From: "Ashish Vijaywargiya" <vi...@gmail.com>
>>
>>> My vote will be to keep two themes in the project. IMO Flatgrey theme is
>>> the best to keep as the default one for the project.
>>>
>>> --
>>> Ashish
>>>
>>> On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato <
>>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>>
>>>> Jacopo
>>>
>>>
>>

Re: Lose Weight Program for OFBiz - themes

[Mansour Al Akeel <ma...@gmail.com>]

Jacques,
We use RTL.
May be you are right about the the ease of use to find an item, but
the user who has permission to all these functionality is an admin,
and normally, she is comfortable finding any item quickly. The rest of
the uses don't have that much items and menus shown.

I know, other themes may look better, or fancier, but most users use
flat gray to base their work on and extend/customize it, because it's
easier and cleaner. I am not sure if bigger organization prefer
fancier look and feel over cleaner. And to be honest, I think flat
gray looks more professional than others. Therefore, it give a
positive first impression, when demonstrated.

Additional themes may still exist beside FlatGray, but I recommend to
make it the default one.


On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux
<ja...@les7arts.com> wrote:
> I see that most people prefer Flat Grey.
>
> Let me explain why I prefer Tomahawk.
>
> Did you ever wonder why the paper we write on has more than often a greater
> height than width, why newspaper have many columns, etc.
> Here is an answer
> http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns
>
> OK, my argument: don't you feel a pain to find an application, a menu entry
> in Flat Grey? No? Then you are used to find it at some place and don't care
> anymore. Now just imagine the same for a new user...
>
> This is where Tomahawk is better. It's far easier to find an entry in 2
> colums (applications in Tomahawk) than in 7 columns (applications in Flat
> Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in
> Flat Grey). Just try it
>
> Another point: Product screens are awful in Flat Grey (to many buttons for
> menus, hard to spot). Though actually I believe Tomahawk would benefit from
> a third column, for instance for Product. This could be 2 twin columns if
> more than, say, 15 entries would show in a column. Like we have for
> Applications, though not sure how it's organized. I mean why some are in
> right column and other in left one? Also something wich could help spot
> entries quicker would be to allow sorting entries in menus by language. It's
> now only done based on English.
>
> OK, now there is the RTL feature. Who use it? Few I guess
> (http://en.wikipedia.org/wiki/Right-to-left
> http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does not
> diminish RTL importance, but ponders it in choice for a default theme.
>
> My 2 cts
>
> Jacques
>
>
> From: "Ashish Vijaywargiya" <vi...@gmail.com>
>
>> My vote will be to keep two themes in the project. IMO Flatgrey theme is
>> the best to keep as the default one for the project.
>>
>> --
>> Ashish
>>
>> On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxmedia.com> 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.
>>>
>>> Jacopo
>>
>>
>

Re: Lose Weight Program for OFBiz - themes

[Jacques Le Roux <ja...@les7arts.com>]

I see that most people prefer Flat Grey.

Let me explain why I prefer Tomahawk.

Did you ever wonder why the paper we write on has more than often a greater height than width, why newspaper have many columns, etc.
Here is an answer http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns

OK, my argument: don't you feel a pain to find an application, a menu entry in Flat Grey? No? Then you are used to find it at some 
place and don't care anymore. Now just imagine the same for a new user...

This is where Tomahawk is better. It's far easier to find an entry in 2 colums (applications in Tomahawk) than in 7 columns 
(applications in Flat Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in Flat Grey). Just try it

Another point: Product screens are awful in Flat Grey (to many buttons for menus, hard to spot). Though actually I believe Tomahawk 
would benefit from a third column, for instance for Product. This could be 2 twin columns if more than, say, 15 entries would show 
in a column. Like we have for Applications, though not sure how it's organized. I mean why some are in right column and other in 
left one? Also something wich could help spot entries quicker would be to allow sorting entries in menus by language. It's now only 
done based on English.

OK, now there is the RTL feature. Who use it? Few I guess (http://en.wikipedia.org/wiki/Right-to-left 
http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does not diminish RTL importance, but ponders it in choice for a 
default theme.

My 2 cts

Jacques


From: "Ashish Vijaywargiya" <vi...@gmail.com>
> My vote will be to keep two themes in the project. IMO Flatgrey theme is
> the best to keep as the default one for the project.
>
> --
> Ashish
>
> On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxmedia.com> 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.
>>
>> Jacopo
> 

Re: Lose Weight Program for OFBiz - themes

[Ashish Vijaywargiya <vi...@gmail.com>]

My vote will be to keep two themes in the project. IMO Flatgrey theme is
the best to keep as the default one for the project.

--
Ashish

On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> 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.
>
> Jacopo

Re: Lose Weight Program for OFBiz - themes

[Pierre Smits <pi...@gmail.com>]

I prefer to keep the Flat Grey and one other.

Op 20 maart 2012 12:48 schreef Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> het volgende:

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

Re: Lose Weight Program for OFBiz - themes

[Divesh Dutta <di...@hotwaxmedia.com>]

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

Lose Weight Program for OFBiz - themes

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Jacopo

Re: Lose Weight Program for OFBiz - guiapp and pos

[Divesh Dutta <di...@hotwaxmedia.com>]

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" <ja...@hotwaxmedia.com>
>>>>> 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 
>> 
> 

Re: Lose Weight Program for OFBiz - guiapp and pos

[Scott Gray <sc...@hotwaxmedia.com>]

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" <ja...@hotwaxmedia.com>
>>>> 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 
> 

Re: Lose Weight Program for OFBiz - guiapp and pos

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Makes sense

Jacopo

On Mar 20, 2012, at 3:58 PM, Jacques Le Roux wrote:

> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> 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 

Re: Lose Weight Program for OFBiz - guiapp and pos

[Nicolas Malin <ma...@librenberry.net>]

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 : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/

Re: Lose Weight Program for OFBiz - guiapp and pos

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Lose Weight Program for OFBiz - guiapp and pos

[Olivier Heintz <ho...@nereide.biz>]

Le 21/03/2012 21:56, Jacques Le Roux a écrit :
> From: "Olivier Heintz" <ho...@nereide.biz>
>> Le 21/03/2012 19:02, Jacques Le Roux a écrit :
>>> From: "Olivier Heintz" <ho...@nereide.biz>
>>>> Le 20/03/2012 15:58, Jacques Le Roux a écrit :
>>>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>>>>> 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
>>>>
>>>
>>
>

Re: Lose Weight Program for OFBiz - guiapp and pos

[Jacques Le Roux <ja...@les7arts.com>]

From: "Olivier Heintz" <ho...@nereide.biz>
> Le 21/03/2012 19:02, Jacques Le Roux a écrit :
>> From: "Olivier Heintz" <ho...@nereide.biz>
>>> Le 20/03/2012 15:58, Jacques Le Roux a écrit :
>>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>>>> 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?

Jacques

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

Re: Lose Weight Program for OFBiz - guiapp and pos

[Olivier Heintz <ho...@nereide.biz>]

Le 21/03/2012 19:02, Jacques Le Roux a écrit :
> From: "Olivier Heintz" <ho...@nereide.biz>
>> Le 20/03/2012 15:58, Jacques Le Roux a écrit :
>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>>> 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
>
> Jacques
>
>>>
>>> Jacques
>>
>

Re: Lose Weight Program for OFBiz - guiapp and pos

[Jacques Le Roux <ja...@les7arts.com>]

From: "Olivier Heintz" <ho...@nereide.biz>
> Le 20/03/2012 15:58, Jacques Le Roux a écrit :
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>> 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?

Jacques

>>
>> Jacques
>

Re: Lose Weight Program for OFBiz - guiapp and pos

[Olivier Heintz <ho...@nereide.biz>]

Le 20/03/2012 15:58, Jacques Le Roux a écrit :
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> 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
>
> Jacques

Re: Lose Weight Program for OFBiz - guiapp and pos

[Jacques Le Roux <ja...@les7arts.com>]

From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> 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 

Re: Lose Weight Program for OFBiz - guiapp and pos

[Olivier Heintz <ho...@nereide.biz>]

Le 21/03/2012 17:40, Jacopo Cappellato a écrit :
> On Mar 21, 2012, at 5:26 PM, Olivier Heintz wrote:
>
>> +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz
>>
>> ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-)
> Just to avoid any confusion:
> * with this +1 you are asking to keep projectmgr as it is now (specialpurpose)
no
> * we do not have "official Apache subprojects" in the small OFBiz community because they could be an overkill for what we do (subprojects needs PMC etc...) and we should be careful to even evaluate this path because it will add a lot of "paperwork" to our daily processes
ok
> * transforming the architecture of the component(s) to enable plug-in can be discussed, even if in some ways they are already plugins; but I am wide open to discuss/evaluate your new proposals even if this discussion should be kept separate from the current thread
I have started a dedicated thread about it 3 days ago (OFBiz Plugin 
Management, status and propositions) ;-)

a plug-in repository is a directory, so it's possible to add it in svn 
repository in the same level that ofbiz, (if it's authorized by Apache 
rules)

IMO it's important to say to the community that, for example projectmgr 
is still in the Apache-OFBiz project even if it's necessary to do 
something after downloading ofbiz to install more "things"
> Jacopo

Re: Lose Weight Program for OFBiz - guiapp and pos

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On Mar 21, 2012, at 5:26 PM, Olivier Heintz wrote:

> +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz
> 
> ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-)

Just to avoid any confusion:
* with this +1 you are asking to keep projectmgr as it is now (specialpurpose)
* we do not have "official Apache subprojects" in the small OFBiz community because they could be an overkill for what we do (subprojects needs PMC etc...) and we should be careful to even evaluate this path because it will add a lot of "paperwork" to our daily processes
* transforming the architecture of the component(s) to enable plug-in can be discussed, even if in some ways they are already plugins; but I am wide open to discuss/evaluate your new proposals even if this discussion should be kept separate from the current thread

Jacopo

Re: Lose Weight Program for OFBiz - guiapp and pos

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

As a next step, after all these threads about the slim down will settle down, we should probably, as a community, start to prepare the plan of action, aka roadmap (we could use Jira for it): add there all the actionable tasks coming out of this discussions; then, in these mailing lists we should also start to discuss, as a community, what are the other priorities/goals for the next few months of the project. We should probably start slowly with some cleanup tasks and refactoring of old code, bug fixes etc... but we could also come up with some more interesting priorities (like JCR or reporting tools): then, based on the priorities identified by the community we will start to explore how to design them; if an agreement is found we will add the tasks to the roadmap as well; then we will have a clear and shared plan of actions to keep us all busy for a while
If migration to portlets will be a priority item is something that should be discussed with the community: the community is small and it should stay focused on a few key goals at the time; if the community will decide that the migration to portlets is something desirable then we will definitely explore this concept.

Jacopo

On Mar 21, 2012, at 5:33 PM, Pierre @GMail wrote:

> Hi Olivier,
> 
> I would love to exchange thoughts regarding migration to portlets. 
> 
> Regards,
> 
> Pierre
> 
> Sent from my iPhone
> 
> On 21 mrt. 2012, at 17:26, Olivier Heintz <ho...@nereide.biz> wrote:
> 
>> Le 21/03/2012 11:50, Pierre Smits a écrit :
>>> A) removal of framework/guiapp out of framework: +1
>>> 
>>> B) move specialpurpose/pos to 'Extras' +1
>>> 
>>> I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras' as the majority of my customers use this. However, if it goes to 'Extras' I would like to assist in maintaining it.
>> +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz
>> 
>> ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-)
>>> Regards,
>>> 
>>> Pierre
>>> 
>>> Op 20 maart 2012 12:47 schreef Jacopo Cappellato<
>>> jacopo.cappellato@hotwaxmedia.com>  het volgende:
>>> 
>>>>> 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?
>>>> 
>>>> 
>> 

Re: Lose Weight Program for OFBiz - guiapp and pos

["Pierre @GMail" <pi...@gmail.com>]

Hi Olivier,

I would love to exchange thoughts regarding migration to portlets. 

Regards,

Pierre

Sent from my iPhone

On 21 mrt. 2012, at 17:26, Olivier Heintz <ho...@nereide.biz> wrote:

> Le 21/03/2012 11:50, Pierre Smits a écrit :
>> A) removal of framework/guiapp out of framework: +1
>> 
>> B) move specialpurpose/pos to 'Extras' +1
>> 
>> I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras' as the majority of my customers use this. However, if it goes to 'Extras' I would like to assist in maintaining it.
> +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz
> 
> ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-)
>> Regards,
>> 
>> Pierre
>> 
>> Op 20 maart 2012 12:47 schreef Jacopo Cappellato<
>> jacopo.cappellato@hotwaxmedia.com>  het volgende:
>> 
>>>> 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?
>>> 
>>> 
> 

Re: Lose Weight Program for OFBiz - guiapp and pos

[Olivier Heintz <ho...@nereide.biz>]

Le 21/03/2012 11:50, Pierre Smits a écrit :
> A) removal of framework/guiapp out of framework: +1
>
> B) move specialpurpose/pos to 'Extras' +1
>
> I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras' as the majority of my customers use this. However, if it goes to 'Extras' I would like to assist in maintaining it.
+1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz

ps: most of our(the company I'm working for) future contribution will be 
complete Projectmgr migration to portlet ;-)
> Regards,
>
> Pierre
>
> Op 20 maart 2012 12:47 schreef Jacopo Cappellato<
> jacopo.cappellato@hotwaxmedia.com>  het volgende:
>
>>> 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?
>>
>>

Re: Lose Weight Program for OFBiz - guiapp and pos

[Pierre Smits <pi...@gmail.com>]

A) removal of framework/guiapp out of framework: +1

B) move specialpurpose/pos to 'Extras' +1

I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras'
as the majority of my customers use this. However, if it goes to 'Extras' I
would like to assist in maintaining it.

Regards,

Pierre

Op 20 maart 2012 12:47 schreef Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> het volgende:

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

Lose Weight Program for OFBiz - guiapp and pos

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty

[Jacques Le Roux <ja...@les7arts.com>]

You could maybe contribute your work on it?

Jacques

From: "J. Eckard" <ec...@redrocketcorp.com>
>I currently use jetty, and keep it updated internally to track the jetty 6 codebase. I have no problem with it being removed from 
>the framework, as long as we don't assume or require tomcat in the future.
>
>
> On Mar 20, 2012, at 7:48 AM, Jacopo Cappellato wrote:
>
>>
>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>>
>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>>
>>> E) specialpurpose/workflow: move to "Attic"
>>>
>>> F) specialpurpose/shark: move to "Attic"
>>>
>>> J) framework/appserver: move to "Extras"
>>>
>>> K) framework/jetty: move to "Extras" (or "Attic")
>>
>> The above are components/features that don't seem to be used/maintained by the community: some of them are very old (workflow, 
>> shark, appserver, jetty), some of them are experimental (shark, seleniumxml), some of them are very specialized (debian).
>> I have proposed some of them for the Attic and some of them for the Extras but in theory all of them could go to Extras if we 
>> find at least one maintainer for each; if not, each of them could go to Attic.
>> Any ideas? volunteers (OFBiz committers or not)?
>> No one objected or commented on them so far (so I suspect that there could be a lazy consensus); for the seleniumxml code there 
>> was also a thread some weeks ago in the user list where there seemed to be a general consensus (also from the original 
>> contributors of the work) for the removal (apart from Hans who is using it, it doesn't seem to be used much by the community).
>>
>> Jacopo
>>
>
> 

Re: Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty

["J. Eckard" <ec...@redrocketcorp.com>]

I currently use jetty, and keep it updated internally to track the jetty 6 codebase. I have no problem with it being removed from the framework, as long as we don't assume or require tomcat in the future.


On Mar 20, 2012, at 7:48 AM, Jacopo Cappellato wrote:

> 
>> C) $OFBIZ_HOME/debian: move to "Attic"
>> 
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>> 
>> E) specialpurpose/workflow: move to "Attic"
>> 
>> F) specialpurpose/shark: move to "Attic"
>> 
>> J) framework/appserver: move to "Extras"
>> 
>> K) framework/jetty: move to "Extras" (or "Attic")
> 
> The above are components/features that don't seem to be used/maintained by the community: some of them are very old (workflow, shark, appserver, jetty), some of them are experimental (shark, seleniumxml), some of them are very specialized (debian).
> I have proposed some of them for the Attic and some of them for the Extras but in theory all of them could go to Extras if we find at least one maintainer for each; if not, each of them could go to Attic.
> Any ideas? volunteers (OFBiz committers or not)?
> No one objected or commented on them so far (so I suspect that there could be a lazy consensus); for the seleniumxml code there was also a thread some weeks ago in the user list where there seemed to be a general consensus (also from the original contributors of the work) for the removal (apart from Hans who is using it, it doesn't seem to be used much by the community).
> 
> Jacopo
> 

Re: Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty

[Pierre Smits <pi...@gmail.com>]

On all: +1

Regards,

Pierre

Op 20 maart 2012 12:48 schreef Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> het volgende:

>
> > C) $OFBIZ_HOME/debian: move to "Attic"
> >
> > D) the seleniumxml code in framework/testtools: move to "Attic"
> >
> > E) specialpurpose/workflow: move to "Attic"
> >
> > F) specialpurpose/shark: move to "Attic"
> >
> > J) framework/appserver: move to "Extras"
> >
> > K) framework/jetty: move to "Extras" (or "Attic")
>
> The above are components/features that don't seem to be used/maintained by
> the community: some of them are very old (workflow, shark, appserver,
> jetty), some of them are experimental (shark, seleniumxml), some of them
> are very specialized (debian).
> I have proposed some of them for the Attic and some of them for the Extras
> but in theory all of them could go to Extras if we find at least one
> maintainer for each; if not, each of them could go to Attic.
> Any ideas? volunteers (OFBiz committers or not)?
> No one objected or commented on them so far (so I suspect that there could
> be a lazy consensus); for the seleniumxml code there was also a thread some
> weeks ago in the user list where there seemed to be a general consensus
> (also from the original contributors of the work) for the removal (apart
> from Hans who is using it, it doesn't seem to be used much by the
> community).
>
> Jacopo
>
>

Re: Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty

[Jacques Le Roux <ja...@les7arts.com>]

From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> C) $OFBIZ_HOME/debian: move to "Attic"
>>
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>
>> E) specialpurpose/workflow: move to "Attic"
>>
>> F) specialpurpose/shark: move to "Attic"
>>
>> J) framework/appserver: move to "Extras"

This one I could try to maintain. The others can move to Attic for me.
But I must say that recently I was not able to follow/answer the recent demands after Tomcat evolution.
So maybe in futur to Attic too, and could be resurrected later...

Jacques

>> K) framework/jetty: move to "Extras" (or "Attic")
>
> The above are components/features that don't seem to be used/maintained by the community: some of them are very old (workflow, 
> shark, appserver, jetty), some of them are experimental (shark, seleniumxml), some of them are very specialized (debian).
> I have proposed some of them for the Attic and some of them for the Extras but in theory all of them could go to Extras if we find 
> at least one maintainer for each; if not, each of them could go to Attic.
> Any ideas? volunteers (OFBiz committers or not)?
> No one objected or commented on them so far (so I suspect that there could be a lazy consensus); for the seleniumxml code there 
> was also a thread some weeks ago in the user list where there seemed to be a general consensus (also from the original 
> contributors of the work) for the removal (apart from Hans who is using it, it doesn't seem to be used much by the community).
>
> Jacopo
>
> 

Re: Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty

[ad...@sandglass-software.com]

I have always had a problem with OS-specific code being maintained in  
OFBiz. Granted, we have some artifacts that must take the OS into  
consideration in order to get OFBiz to work, but it appears to me the  
Debian stuff doesn't fall into that category (I could be wrong, please  
correct me if I am).

For example, we have start scripts (startofbiz.*) as a convenience for  
users running on various platforms, but those scripts are somewhat  
generic. Is the Debian stuff similar to that or not?

+1 on shark and workflow

+0 on the rest.

Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:

>
>> C) $OFBIZ_HOME/debian: move to "Attic"
>>
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>
>> E) specialpurpose/workflow: move to "Attic"
>>
>> F) specialpurpose/shark: move to "Attic"
>>
>> J) framework/appserver: move to "Extras"
>>
>> K) framework/jetty: move to "Extras" (or "Attic")
>
> The above are components/features that don't seem to be  
> used/maintained by the community: some of them are very old  
> (workflow, shark, appserver, jetty), some of them are experimental  
> (shark, seleniumxml), some of them are very specialized (debian).
> I have proposed some of them for the Attic and some of them for the  
> Extras but in theory all of them could go to Extras if we find at  
> least one maintainer for each; if not, each of them could go to Attic.
> Any ideas? volunteers (OFBiz committers or not)?
> No one objected or commented on them so far (so I suspect that there  
> could be a lazy consensus); for the seleniumxml code there was also  
> a thread some weeks ago in the user list where there seemed to be a  
> general consensus (also from the original contributors of the work)  
> for the removal (apart from Hans who is using it, it doesn't seem to  
> be used much by the community).
>
> Jacopo
>
>

Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

> C) $OFBIZ_HOME/debian: move to "Attic"
> 
> D) the seleniumxml code in framework/testtools: move to "Attic"
> 
> E) specialpurpose/workflow: move to "Attic"
> 
> F) specialpurpose/shark: move to "Attic"
> 
> J) framework/appserver: move to "Extras"
> 
> K) framework/jetty: move to "Extras" (or "Attic")

The above are components/features that don't seem to be used/maintained by the community: some of them are very old (workflow, shark, appserver, jetty), some of them are experimental (shark, seleniumxml), some of them are very specialized (debian).
I have proposed some of them for the Attic and some of them for the Extras but in theory all of them could go to Extras if we find at least one maintainer for each; if not, each of them could go to Attic.
Any ideas? volunteers (OFBiz committers or not)?
No one objected or commented on them so far (so I suspect that there could be a lazy consensus); for the seleniumxml code there was also a thread some weeks ago in the user list where there seemed to be a general consensus (also from the original contributors of the work) for the removal (apart from Hans who is using it, it doesn't seem to be used much by the community).

Jacopo

Re: Lose Weight Program for OFBiz - Birt and BI

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Lose Weight Program for OFBiz - Birt and BI

[Scott Gray <sc...@hotwaxmedia.com>]

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 <ma...@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 <an...@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 <ma...@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
>>>>> <er...@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: sales@cohsoft.com.au
>>>> 
>>>> Bonsai ERP, the all-inclusive ERP system
>>>> http://www.bonsaierp.com.au/

Re: Lose Weight Program for OFBiz - Birt and BI

[Jacques Le Roux <ja...@les7arts.com>]

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 <ma...@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 <an...@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 <ma...@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
>>>> <er...@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: sales@cohsoft.com.au
>>>
>>> Bonsai ERP, the all-inclusive ERP system
>>> http://www.bonsaierp.com.au/

Re: Lose Weight Program for OFBiz - Birt and BI

[Mansour Al Akeel <ma...@gmail.com>]

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 <an...@cohsoft.com.au> 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 <ma...@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 <an...@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 <ma...@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
>> >> <er...@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: sales@cohsoft.com.au
>> >
>> > Bonsai ERP, the all-inclusive ERP system
>> > http://www.bonsaierp.com.au/
>>
>
>
>
> --
> 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: sales@cohsoft.com.au
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/

Re: Lose Weight Program for OFBiz - Birt and BI

[Anne <an...@cohsoft.com.au>]

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 <ma...@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 <an...@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 <ma...@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
> >> <er...@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: sales@cohsoft.com.au
> >
> > Bonsai ERP, the all-inclusive ERP system
> > http://www.bonsaierp.com.au/
>



-- 
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: sales@cohsoft.com.au

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

Re: Lose Weight Program for OFBiz - Birt and BI

[Mansour Al Akeel <ma...@gmail.com>]

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 <an...@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 <ma...@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
>> <er...@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: sales@cohsoft.com.au
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/

Re: Lose Weight Program for OFBiz - Birt and BI

[Anne <an...@cohsoft.com.au>]

+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 <ma...@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
> <er...@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: sales@cohsoft.com.au

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

Re: Lose Weight Program for OFBiz - Birt and BI

[Mansour Al Akeel <ma...@gmail.com>]

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
<er...@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

Re: Lose Weight Program for OFBiz - Birt and BI

[Erwan de FERRIERES <er...@nereide.fr>]

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

Re: Lose Weight Program for OFBiz - Birt and BI

[Nicolas Malin <ma...@librenberry.net>]

Le 22/03/2012 04:47, Hans Bakker a écrit :
> Hi Anne,
>
> Birt has several advantages in the current integration and we use it 
> often on the warehouse entities. These entities are mostly not in the 
> BI component but in the application components.
>
> Jasper reports and all others do not use the ofbiz framework but work 
> on the JDBC driver directly or even worse only work on mysql or are 
> mostly commercial.
Just to correct this, Birt is integrate currently in OFBiz (and tks a 
lot for the work :) ), but jasper to if you load the interface. By 
default you can use JDBC driver with these tools, put all have an api to 
integrate it. Last time we work on integration with open office, it's 
just a data preparation by the technical interface. If Birt move on 
extra, a goal will be the simplify integration between service engine 
and report layer.

Nicolas

>
> Integration with Birt is using the ofbiz framework and works on any 
> data base that ofbiz runs on.
>
> Regards,
> Hans
>
>
> With BI i mean the BI screens/forms, not the entities.
>
> On 03/22/2012 09:47 AM, Anne wrote:
>> I thought Birt was a report generation/layout tool, like 
>> JasperReports and
>> many others. I don't understand why it would have anything to do with
>> datawarehousing.
>>
>> I agree with Hans that datawarehousing is important. But I think that
>> should be part of BI, or other (possibly framework) functionality not 
>> tied
>> to presentation.
>>
>> With the single exception of point 5, aren't the listed positives all
>> related to non-Birt functionality? Birt just manages the 
>> presentation? And
>> point 5 could be handled by competitors to Birt?
>>
>> Cheers,
>> Anne.
>>
>> On 22 March 2012 12:38, Hans Bakker<ma...@antwebsystems.com>  
>> 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
>>>>
>>>
>>
>


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

Re: Lose Weight Program for OFBiz - Birt and BI

[Hans Bakker <ma...@antwebsystems.com>]

Hi Anne,

Birt has several advantages in the current integration and we use it 
often on the warehouse entities. These entities are mostly not in the BI 
component but in the application components.

Jasper reports and all others do not use the ofbiz framework but work on 
the JDBC driver directly or even worse only work on mysql or are mostly 
commercial.

Integration with Birt is using the ofbiz framework and works on any data 
base that ofbiz runs on.

Regards,
Hans


With BI i mean the BI screens/forms, not the entities.

On 03/22/2012 09:47 AM, Anne wrote:
> I thought Birt was a report generation/layout tool, like JasperReports and
> many others. I don't understand why it would have anything to do with
> datawarehousing.
>
> I agree with Hans that datawarehousing is important. But I think that
> should be part of BI, or other (possibly framework) functionality not tied
> to presentation.
>
> With the single exception of point 5, aren't the listed positives all
> related to non-Birt functionality? Birt just manages the presentation? And
> point 5 could be handled by competitors to Birt?
>
> Cheers,
> Anne.
>
> On 22 March 2012 12:38, Hans Bakker<ma...@antwebsystems.com>  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
>>>
>>
>

Re: Lose Weight Program for OFBiz - Birt and BI

[Anne <an...@cohsoft.com.au>]

I thought Birt was a report generation/layout tool, like JasperReports and
many others. I don't understand why it would have anything to do with
datawarehousing.

I agree with Hans that datawarehousing is important. But I think that
should be part of BI, or other (possibly framework) functionality not tied
to presentation.

With the single exception of point 5, aren't the listed positives all
related to non-Birt functionality? Birt just manages the presentation? And
point 5 could be handled by competitors to Birt?

Cheers,
Anne.

On 22 March 2012 12:38, Hans Bakker <ma...@antwebsystems.com> 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
>>
>
>


-- 
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: sales@cohsoft.com.au

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

Re: Lose Weight Program for OFBiz - Birt and BI

[Hans Bakker <ma...@antwebsystems.com>]

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" <ma...@antwebsystems.com>
>> 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
>>

Re: Lose Weight Program for OFBiz - Birt and BI

[Jacques Le Roux <ja...@les7arts.com>]

I mean the framework should know nothing about applications

>>> 6. Incorporates the warehouse entities.


Jacques

From: "Hans Bakker" <ma...@antwebsystems.com>
> 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
>

Re: Lose Weight Program for OFBiz - Birt and BI

[Hans Bakker <ma...@antwebsystems.com>]

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

Re: Lose Weight Program for OFBiz - Birt and BI

[Jacques Le Roux <ja...@les7arts.com>]

>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

Re: Lose Weight Program for OFBiz - Birt and BI

[Hans Bakker <ma...@antwebsystems.com>]

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

Re: Lose Weight Program for OFBiz - Birt and BI

[Pierre Smits <pi...@gmail.com>]

Currently, rptdesign is used in specialpurpose applications like ebaystore
and scrum, but also in core applications (accounting, order and product).
We have to provide reports in our applications, as it would be difficult to
maintain the concept of  completeness of functionality without them.
Endusers requirements always dictate some kind of reports in applications.

I prefer to have a working solution ootb in OFBiz. Birt delivers that at
the moment.

Removing it creates another proposition issue (on top of all the others we
can think of why OFBiz is hard to sell).

Replacing it by something else would dictate roadmapping.

Regards,

Pierre




Op 20 maart 2012 12:47 schreef Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> het volgende:

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

Re: Lose Weight Program for OFBiz - Birt and BI

[Nicolas Malin <ma...@librenberry.net>]

Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>> 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?
Currently, we work on a POC to use content for reporting, the report 
mechanism is selected by the template type. We implement our first 
reports with openoffice but I don't see blocking to use birt, jasper or 
other. With this methods, all report engine can move on Extras and when 
you deploy, you select for specific report the content thus the desired 
engine.

My vision : by default Apache OFBiz embed Xsl-fo and when you download a 
other report engine, it give some example and standard content reporting.

+1 to move birt in extras :)
> 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


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

Re: Lose Weight Program for OFBiz - Birt and BI

[Olivier Heintz <ho...@nereide.biz>]

+1 birt to extra
and there will also a jasperReport in extras

Le 20/03/2012 15:34, Mansour Al Akeel a écrit :
> +1 birt to Extra.
>
>
> On Tue, Mar 20, 2012 at 10:31 AM,<ad...@sandglass-software.com>  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<ja...@hotwaxmedia.com>:
>>
>>>> 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
>>
>>
>>

Re: Lose Weight Program for OFBiz - Birt and BI

[Mansour Al Akeel <ma...@gmail.com>]

+1 birt to Extra.


On Tue, Mar 20, 2012 at 10:31 AM,  <ad...@sandglass-software.com> 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 <ja...@hotwaxmedia.com>:
>
>>>
>>> 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
>
>
>
>

Re: Lose Weight Program for OFBiz - Birt and BI

[Adrian Crum <ad...@sandglass-software.com>]

We could include a metadata interface that external reporting tools to 
can use to generate reports.

-Adrian

On 4/3/2012 10:27 AM, Divesh Dutta wrote:
> +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, adrian.crum@sandglass-software.com 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<ja...@hotwaxmedia.com>:
>>
>>>> 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
>>
>>

Re: Lose Weight Program for OFBiz - Birt and BI

[Divesh Dutta <di...@hotwaxmedia.com>]

+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, adrian.crum@sandglass-software.com 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 <ja...@hotwaxmedia.com>:
> 
>>> 
>>> 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
> 
> 
> 

Re: Lose Weight Program for OFBiz - Birt and BI

[Anne <an...@cohsoft.com.au>]

+1 for Birt to extras.

Most of the useful reports OOTB are currently fo.

+1 to JasperReports in extras. I'm happy to volunteer for that one.

Cheers,
Anne.

On 22 March 2012 04:59, Jacques Le Roux <ja...@les7arts.com>wrote:

> From: "Olivier Heintz" <ho...@nereide.biz>
>
>  Le 20/03/2012 15:31, adrian.crum@sandglass-**software.com<ad...@sandglass-software.com>a écrit :
>>
>>> 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.
>>>
>> It will be nice if there is a default solution in OFBiz kernel to
>> maximize ready-to-use report and for small company which have not yet a
>> real reporting tool.
>>
>
> Then we have fo.ftl files and PDF rendering. Minimalistic but working.
>
> Jacques
>
>
>
>>> -Adrian
>>>
>>> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>
>>> >:
>>>
>>>
>>>>> 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
>>>>
>>>
>>>
>>>
>>>
>>>
>>


-- 
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: sales@cohsoft.com.au

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

Re: Lose Weight Program for OFBiz - Birt and BI

[Jacques Le Roux <ja...@les7arts.com>]

From: "Olivier Heintz" <ho...@nereide.biz>
> Le 20/03/2012 15:31, adrian.crum@sandglass-software.com a écrit :
>> 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.
> It will be nice if there is a default solution in OFBiz kernel to maximize ready-to-use report and for small company which have 
> not yet a real reporting tool.

Then we have fo.ftl files and PDF rendering. Minimalistic but working.

Jacques

>>
>> -Adrian
>>
>> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:
>>
>>>>
>>>> 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
>>
>>
>>
>>
> 

Re: Lose Weight Program for OFBiz - Birt and BI

[Olivier Heintz <ho...@nereide.biz>]

Le 20/03/2012 15:31, adrian.crum@sandglass-software.com a écrit :
> 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.
It will be nice if there is a default solution in OFBiz kernel to 
maximize ready-to-use report and for small company which have not yet a 
real reporting tool.
>
> -Adrian
>
> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:
>
>>>
>>> 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
>
>
>
>

Re: Lose Weight Program for OFBiz - Birt and BI

[ad...@sandglass-software.com]

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 <ja...@hotwaxmedia.com>:

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

Lose Weight Program for OFBiz - Birt and BI

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Lose Weight Program for OFBiz - documents

[Jacques Le Roux <ja...@les7arts.com>]

From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>
>
> The broader topic is to move all the artifacts related to online help out of the framework; they should all live under 
> "applications".

What about documents currently in documents folders under framework folders?

Some could be replaced by README, like FrameworkBase.xml.
Not sure for stuff like ReceivingEmail.xml which speaks about MCA (same for other framework specific features)

Jacques 

Re: Lose Weight Program for OFBiz - documents

[Jacques Le Roux <ja...@les7arts.com>]

And there are parts in framework

Jacques

From: "Hans Bakker" <ma...@antwebsystems.com>
> The idea behind this that documents in wiki are not according the 
> version..(only the latest)
> 
> This directory has it for the related version AND can be in different 
> languages and formats: html, pdf
> 
> do judge before you understand......
> Regards,
> 
> Hans
> 
> 
> On 03/21/2012 06:01 PM, Pierre Smits wrote:
>> +1. This is an example of bloat. Keeping ill-maintained static documents in
>> OFBiz (the suite) that are also available through the OFBiz website is not
>> adding value.
>>
>> Regards,
>>
>> Pierre
>>
>> Op 20 maart 2012 12:48 schreef Jacopo Cappellato<
>> jacopo.cappellato@hotwaxmedia.com>  het volgende:
>>
>>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>>>
>>> The broader topic is to move all the artifacts related to online help out
>>> of the framework; they should all live under "applications".
>>>
>>>
>>>
>

Re: Lose Weight Program for OFBiz - documents

[Hans Bakker <ma...@antwebsystems.com>]

The idea behind this that documents in wiki are not according the 
version..(only the latest)

This directory has it for the related version AND can be in different 
languages and formats: html, pdf

do judge before you understand......
Regards,

Hans


On 03/21/2012 06:01 PM, Pierre Smits wrote:
> +1. This is an example of bloat. Keeping ill-maintained static documents in
> OFBiz (the suite) that are also available through the OFBiz website is not
> adding value.
>
> Regards,
>
> Pierre
>
> Op 20 maart 2012 12:48 schreef Jacopo Cappellato<
> jacopo.cappellato@hotwaxmedia.com>  het volgende:
>
>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>>
>> The broader topic is to move all the artifacts related to online help out
>> of the framework; they should all live under "applications".
>>
>>
>>

Re: Lose Weight Program for OFBiz - documents

[Pierre Smits <pi...@gmail.com>]

+1. This is an example of bloat. Keeping ill-maintained static documents in
OFBiz (the suite) that are also available through the OFBiz website is not
adding value.

Regards,

Pierre

Op 20 maart 2012 12:48 schreef Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> het volgende:

>
> > O) framework/documents: move the content to Wiki and then move to "Attic"
> >
>
> The broader topic is to move all the artifacts related to online help out
> of the framework; they should all live under "applications".
>
>
>

Lose Weight Program for OFBiz - documents

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

> O) framework/documents: move the content to Wiki and then move to "Attic"
> 

The broader topic is to move all the artifacts related to online help out of the framework; they should all live under "applications".

Re: Lose Weight Program for OFBiz

[Pierre Smits <pi...@gmail.com>]

Hi Hans,

Of course you do not have to agree. But, like you implied earlier: let's
put it to the vote and see what the outcome will. I assume that you will
adhere/comply to the result as well.

Regards,

Pierre

Op 19 maart 2012 13:15 schreef Hans Bakker
<ma...@antwebsystems.com>het volgende:

> Jacopo,
>
> I appreciate you reply and effort, can however not agree with you. Perhaps
> for you good reasoning, not for me.
>
> Regards,
> Hans
>
>
>
> On 03/19/2012 05:08 PM, Jacopo Cappellato wrote:
>
>> Hi Hans,
>>
>> please see inline:
>>
>> On Mar 19, 2012, at 9:05 AM, Hans Bakker wrote:
>>
>>  Hi Jacopo,
>>>
>>> Thank you for the effort you spend with OFBiz the last few months. I
>>> generally agree that sure we have to cut the dead wood in the system.
>>> Components and functions which are not used or only halfway implemented
>>> sure, sounds like a good idea to move them out.
>>>
>>> However the reasons you list as 'high maintenance' i do not agree with.
>>> Only with file changes there is work, otherwise it is pretty limited.
>>> Removing half baked code sure, lets remove it.
>>>
>>> The 'not complete' reasons do not apply to several applications and
>>> functions you want to remove because they are complete, like asset
>>> maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component
>>> perhaps better to integrate it with ecommerce), projectmgr and scrum.
>>>
>> The "not complete" is not the only motivation: I have also considered if
>> they seem to be "used" and maintained; or if they follow best practices or
>> if they are very specific: some of them are actually a very specific way to
>> implement a very specific set of requirements and may be better represented
>> as independent optional components that can be downloaded and used only by
>> users with these specific needs.
>> Keeping all them in will also mean that, if and when the community will
>> decide to migrate a technology (e.g. from Freemarker to XYZ or from Screens
>> to ABC or from the OFBiz Framework to Moqui) they will also need to be
>> maintained and migrated by the community... when the user based may be very
>> limited.
>>
>>  Also moving the JCR function out is not a good idea however when not
>>> improved in the next few months using the content manager, i would agree to
>>> a removal.
>>>
>> Keep it mind we are preparing for the creation of the new release branch
>> (12.04): this would mean that all the future releases for 12.04 will be
>> bundled with an incomplete JCR/Jackrabbit integration that duplicates (but
>> not replaces) the existing Component framework. This is alone a good reason
>> for moving this work back to the development branch and will save a lot of
>> future work in backporting features if security issues or bugs will be
>> discovered.
>>
>>  Then I was even more surprised, because reporting is a pretty weak point
>>> in OFBiz, to remove the Birt integration and data warehouse entities.
>>>
>> I agree that reporting is a weak point in OFBiz; I disagree that the
>> integrated Birt component is the answer to this problem: the integration is
>> minimal and the reports that are implemented with Birt are very good
>> example of how weak the current integration is: they have a bunch of data
>> preparation code buried in them and their layout is very simple too. And
>> you still have to define controller entries for the reports and also
>> screen/forms for the parameters to invoke them... this is really a small
>> help provided by the framework; a real integration, ready to be released
>> with OFBiz, should do much more than this (like letting the user to define
>> a new report using the report designer only and then "publish it to OFBiz"
>> from there without requiring all these programming tasks). And as a side
>> effect for having this integration we have to bundle and deliver to all the
>> users a big amount of jars; instead this should be an optional (downloaded
>> separately) component that only interested users should get (and these
>> users will probably already have their own Birt setup). OFbiz should stay
>> lighter and should delegate the decision about what reporting engine to use
>> to the user. I suspect that, if the user community is really using this
>> integration to build reports, we would get a lot of them contributed... and
>> this is not happening.
>>
>>  I cannot agree with the removal of these components, Birt integration
>>> and JCR (in the short term)
>>>
>>>  Fair enough; we will see what others have to say on this subject as
>> well. Then we will take the best decision for the community.
>>
>>  Some other proposals:
>>> 1. I would like to push for more junit tests and use even this as a
>>> measure to keep a component in the system or not. (cobertura minimum
>>> percentage?)
>>>
>> This is a good idea indeed if the presence/lack of junit test will be
>> used as an additional element for the decision; but it can't be the only
>> one because we could have a component that has a lot of junit tests but for
>> some reason is not a good fit for OFBiz (for example because its
>> implementation doesn't follow best practices, or no one is willing to
>> maintain it etc...); in this case it should be removed as well.
>>
>>  2. To have a lead committer appointed for every component in the system
>>> who will check incoming patches and will commit them, to relieve Jacques of
>>> some work.
>>>
>> I don't like very much this because it implies some sort of "ownership"
>> over code.
>>
>>  3. List functions/tasks with every committer, if a committer does not
>>> have a function/task or is not active for a year, put him on the emeritus
>>> list, if he gets active again put him back as a committer on his request.
>>> This to get a real committers (and contributors, see next point) list.
>>> 4. Also list contributors who have a function/task assigned either for
>>> creating documents, reporting errors or supply patches, list the
>>> contributions he/she did so we can keep up if he/she could be nominated to
>>> be a committer.
>>>
>> These last 2 points are probably off topic here (please discuss them in
>> another thread) but I will provide my quick feedback because they are
>> interesting:
>> * I like the idea of point #4 for helping us to keep track of future
>> candidates for being committers; we could also keep track of commit
>> revisions where they patches have been submitted
>> * I don't see the need for such a formal process for #3: it may be
>> interesting to formalize who is active (with commits or reviews etc...) and
>> who is not but it is already quite evident from the lists because we are a
>> small group; this would also add some unnecessary overhead on the
>> community: keep track of contributions, vote to move them to emeritus
>> (contact infra to revoke commit rights?), and back if they want to come
>> back (contact infra to regrant commit rights?)
>> * when we talk about "contributions and commits" as a means to evaluate
>> how much a contributor is helping the project then I would like to stress
>> an important point, that was not considered until now: the
>> contributions/commits must be inline with the current roadmap and
>> priorities chosen by the community; otherwise, even if committer X is
>> committing a huge number of code on a component she is working on for some
>> personal interest, but not solicited by the community, then it would not be
>> considered a "top contributor"
>>
>> Thanks for your comments.
>>
>> Kind regards,
>>
>> Jacopo
>>
>>  Thanks again for your activity, keep up the good work!
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>> On 03/18/2012 04:10 PM, Jacopo Cappellato wrote:
>>>
>>>> In the last period the OFBiz project has grown a lot in shape: the
>>>> implicitly accepted (or tolerated) strategy operated by the active
>>>> committers was that the more features you could add to the official
>>>> repository the better was: you make happy the contributors, making them
>>>> feel like they are a part of something, and each committer could manage the
>>>> code implemented for his/her own projects directly in the OFBiz codebase.
>>>>
>>>> We operated under the concept that, since the code if "free" and the
>>>> author (committer or not) is willing to contribute it, then no one
>>>> should/could complain if it is added to the repository, if it doesn't cause
>>>> immediate problems to others; all in all it is an additional feature that
>>>> may be used by someone else in the future or if not would simply stay there
>>>> without causing any harm.
>>>> Following this strategy we got a lot of code like for example
>>>> Webslinger, seleniumxml, debian packages, all sort of specialpurpose
>>>> applications etc...
>>>>
>>>> Since there was not a central and agreed upon roadmap, no one could
>>>> really state that a contribution was not a good fit for the project: each
>>>> and every committer could add what, in his own personal vision, was good
>>>> for the project.
>>>>
>>>> The wrong assumption is that, since the code if "free" then it doesn't
>>>> harm to include it. This is completely *wrong*: the code is not *free* at
>>>> all because as soon as you add it to the repository then you add a future
>>>> cost to the community: you all know that in the software industry the cost
>>>> to maintain a piece of code is by far greater than the cost to write it;
>>>> and you *have* to maintain the code unless you want to have and distribute
>>>> stale code.
>>>> And this is exactly what we have now:
>>>> * high costs to maintain the code (e.g. I recently spent a lot of hours
>>>> to remove the Webslinger component)
>>>> * stale/unused/half baked code that causes confusion and bad impression
>>>> to user evaluating the quality of our product
>>>>
>>>> The message to all the committers is: when you add code to the
>>>> repository, you are asking the community to take care of its maintenance
>>>> costs forever. So please, add new code only when it is really beneficial to
>>>> the project and to a large audience of committers and users.
>>>>
>>>> It is like feeding a wild animal at the zoo with chips: everyone knows
>>>> it is bad for its health but when you are there it is so nice when it picks
>>>> the food from your own hands and you cannot resist and have to feed it.
>>>>
>>>> OFBiz is now suffering from serious weight issues: the committers
>>>> community is having an hard time to maintain the huge codebase, it is
>>>> difficult to keep track of all the features in the system etc...
>>>>
>>>> I think it is important to start a new phase of the project and focus
>>>> our energy in cleanup and consolidation of what we have. One step in this
>>>> direction is for OFBiz to lose weight.
>>>>
>>>> In order to get the ball rolling and focus on some concrete tasks I am
>>>> providing here some examples of stuff that I would like to see removed from
>>>> the project.
>>>>
>>>> IMPORTANT: Please consider that the list is not based on what I think
>>>> the perfect framework should be (so PLEASE do not reply stating what your
>>>> ideal framework should have), but simply on the following considerations:
>>>> * can the component be easily removed by the project? is it independent
>>>> and can live outside as a plugin?
>>>> * do we need all this custom code? can't we find a simpler, lighter and
>>>> better way to implement this?
>>>> * is this feature used by other code in the system?
>>>> * is the feature functional? or is it largely incomplete?
>>>> * is this an old component/code?
>>>> * is this used by a lot of persons? (this is tricky to decide but you
>>>> can get a feeling of it by reading the mailing lists, considering commit
>>>> activity, the status of the feature etc...)
>>>>
>>>> DISCLAIMER: I know it will be a painful decision because each of us
>>>> reading this will have a connection with some of the code listed below:
>>>> several hours spent on it, great ideas that never came to a finished plan;
>>>> in fact I feel the same for a few of the things in the list.... there are
>>>> great ideas that didn't come to a finalization... it doesn't mean that
>>>> moving them out of the project will kill them and this may actually help to
>>>> get more visibility and different user group; so please when you will read
>>>> it... think to the greater good of the community.
>>>>
>>>> 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"
>>>>
>>>> And now (drums)..... THE LIST - PART 1(but this is really a very first
>>>> pass only, PART 2 will come soon with more granular - subcomponent -
>>>> details):
>>>>
>>>> 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"
>>>>
>>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>>>
>>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>>>
>>>> E) specialpurpose/workflow: move to "Attic"
>>>>
>>>> F) specialpurpose/shark: move to "Attic"
>>>>
>>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>>
>>>> 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"
>>>>
>>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of
>>>> them to "Extras"; keep just one (or two)
>>>>
>>>> J) framework/appserver: move to "Extras"
>>>>
>>>> K) framework/jetty: move to "Extras" (or "Attic")
>>>>
>>>> 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"
>>>>
>>>> N) framework/jcr: move back into the Jackrabbit branch until the work
>>>> is completed and can replace the existing "content framework"
>>>>
>>>> O) framework/documents: move the content to Wiki and then move to
>>>> "Attic"
>>>>
>>>> P) framework/datafile: (who is currently using it?) move to "Extras" or
>>>> "Attic"; we could replace it with commons-csv or similar tool
>>>>
>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>>
>>>> Kind regards,
>>>>
>>>> Jacopo
>>>>
>>>>
>>>
>
>

Re: Lose Weight Program for OFBiz

[Hans Bakker <ma...@antwebsystems.com>]

Jacopo,

I appreciate you reply and effort, can however not agree with you. 
Perhaps for you good reasoning, not for me.

Regards,
Hans


On 03/19/2012 05:08 PM, Jacopo Cappellato wrote:
> Hi Hans,
>
> please see inline:
>
> On Mar 19, 2012, at 9:05 AM, Hans Bakker wrote:
>
>> Hi Jacopo,
>>
>> Thank you for the effort you spend with OFBiz the last few months. I generally agree that sure we have to cut the dead wood in the system. Components and functions which are not used or only halfway implemented sure, sounds like a good idea to move them out.
>>
>> However the reasons you list as 'high maintenance' i do not agree with. Only with file changes there is work, otherwise it is pretty limited. Removing half baked code sure, lets remove it.
>>
>> The 'not complete' reasons do not apply to several applications and functions you want to remove because they are complete, like asset maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component perhaps better to integrate it with ecommerce), projectmgr and scrum.
> The "not complete" is not the only motivation: I have also considered if they seem to be "used" and maintained; or if they follow best practices or if they are very specific: some of them are actually a very specific way to implement a very specific set of requirements and may be better represented as independent optional components that can be downloaded and used only by users with these specific needs.
> Keeping all them in will also mean that, if and when the community will decide to migrate a technology (e.g. from Freemarker to XYZ or from Screens to ABC or from the OFBiz Framework to Moqui) they will also need to be maintained and migrated by the community... when the user based may be very limited.
>
>> Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal.
> Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered.
>
>> Then I was even more surprised, because reporting is a pretty weak point in OFBiz, to remove the Birt integration and data warehouse entities.
> I agree that reporting is a weak point in OFBiz; I disagree that the integrated Birt component is the answer to this problem: the integration is minimal and the reports that are implemented with Birt are very good example of how weak the current integration is: they have a bunch of data preparation code buried in them and their layout is very simple too. And you still have to define controller entries for the reports and also screen/forms for the parameters to invoke them... this is really a small help provided by the framework; a real integration, ready to be released with OFBiz, should do much more than this (like letting the user to define a new report using the report designer only and then "publish it to OFBiz" from there without requiring all these programming tasks). And as a side effect for having this integration we have to bundle and deliver to all the users a big amount of jars; instead this should be an optional (downloaded separately) component that only interested users should get (and these users will probably already have their own Birt setup). OFbiz should stay lighter and should delegate the decision about what reporting engine to use to the user. I suspect that, if the user community is really using this integration to build reports, we would get a lot of them contributed... and this is not happening.
>
>> I cannot agree with the removal of these components, Birt integration and JCR (in the short term)
>>
> Fair enough; we will see what others have to say on this subject as well. Then we will take the best decision for the community.
>
>> Some other proposals:
>> 1. I would like to push for more junit tests and use even this as a measure to keep a component in the system or not. (cobertura minimum percentage?)
> This is a good idea indeed if the presence/lack of junit test will be used as an additional element for the decision; but it can't be the only one because we could have a component that has a lot of junit tests but for some reason is not a good fit for OFBiz (for example because its implementation doesn't follow best practices, or no one is willing to maintain it etc...); in this case it should be removed as well.
>
>> 2. To have a lead committer appointed for every component in the system who will check incoming patches and will commit them, to relieve Jacques of some work.
> I don't like very much this because it implies some sort of "ownership" over code.
>
>> 3. List functions/tasks with every committer, if a committer does not have a function/task or is not active for a year, put him on the emeritus list, if he gets active again put him back as a committer on his request. This to get a real committers (and contributors, see next point) list.
>> 4. Also list contributors who have a function/task assigned either for creating documents, reporting errors or supply patches, list the contributions he/she did so we can keep up if he/she could be nominated to be a committer.
> These last 2 points are probably off topic here (please discuss them in another thread) but I will provide my quick feedback because they are interesting:
> * I like the idea of point #4 for helping us to keep track of future candidates for being committers; we could also keep track of commit revisions where they patches have been submitted
> * I don't see the need for such a formal process for #3: it may be interesting to formalize who is active (with commits or reviews etc...) and who is not but it is already quite evident from the lists because we are a small group; this would also add some unnecessary overhead on the community: keep track of contributions, vote to move them to emeritus (contact infra to revoke commit rights?), and back if they want to come back (contact infra to regrant commit rights?)
> * when we talk about "contributions and commits" as a means to evaluate how much a contributor is helping the project then I would like to stress an important point, that was not considered until now: the contributions/commits must be inline with the current roadmap and priorities chosen by the community; otherwise, even if committer X is committing a huge number of code on a component she is working on for some personal interest, but not solicited by the community, then it would not be considered a "top contributor"
>
> Thanks for your comments.
>
> Kind regards,
>
> Jacopo
>
>> Thanks again for your activity, keep up the good work!
>>
>> Regards,
>> Hans
>>
>>
>> On 03/18/2012 04:10 PM, Jacopo Cappellato wrote:
>>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>>>
>>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>>
>>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>>>
>>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>>> And this is exactly what we have now:
>>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>>>
>>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>>>
>>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>>>
>>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>>>
>>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>>>
>>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>>>
>>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>>> * is this feature used by other code in the system?
>>> * is the feature functional? or is it largely incomplete?
>>> * is this an old component/code?
>>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>>>
>>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>>>
>>> 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"
>>>
>>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>>>
>>> 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"
>>>
>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>>
>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>>
>>> E) specialpurpose/workflow: move to "Attic"
>>>
>>> F) specialpurpose/shark: move to "Attic"
>>>
>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>
>>> 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"
>>>
>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>>
>>> J) framework/appserver: move to "Extras"
>>>
>>> K) framework/jetty: move to "Extras" (or "Attic")
>>>
>>> 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"
>>>
>>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>>>
>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>>
>>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>>>
>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>
>>> Kind regards,
>>>
>>> Jacopo
>>>
>>

Re: Lose Weight Program for OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Hi Hans,

please see inline:

On Mar 19, 2012, at 9:05 AM, Hans Bakker wrote:

> Hi Jacopo,
> 
> Thank you for the effort you spend with OFBiz the last few months. I generally agree that sure we have to cut the dead wood in the system. Components and functions which are not used or only halfway implemented sure, sounds like a good idea to move them out.
> 
> However the reasons you list as 'high maintenance' i do not agree with. Only with file changes there is work, otherwise it is pretty limited. Removing half baked code sure, lets remove it.
> 
> The 'not complete' reasons do not apply to several applications and functions you want to remove because they are complete, like asset maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component perhaps better to integrate it with ecommerce), projectmgr and scrum.

The "not complete" is not the only motivation: I have also considered if they seem to be "used" and maintained; or if they follow best practices or if they are very specific: some of them are actually a very specific way to implement a very specific set of requirements and may be better represented as independent optional components that can be downloaded and used only by users with these specific needs.
Keeping all them in will also mean that, if and when the community will decide to migrate a technology (e.g. from Freemarker to XYZ or from Screens to ABC or from the OFBiz Framework to Moqui) they will also need to be maintained and migrated by the community... when the user based may be very limited.

> Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal.

Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered.

> Then I was even more surprised, because reporting is a pretty weak point in OFBiz, to remove the Birt integration and data warehouse entities.

I agree that reporting is a weak point in OFBiz; I disagree that the integrated Birt component is the answer to this problem: the integration is minimal and the reports that are implemented with Birt are very good example of how weak the current integration is: they have a bunch of data preparation code buried in them and their layout is very simple too. And you still have to define controller entries for the reports and also screen/forms for the parameters to invoke them... this is really a small help provided by the framework; a real integration, ready to be released with OFBiz, should do much more than this (like letting the user to define a new report using the report designer only and then "publish it to OFBiz" from there without requiring all these programming tasks). And as a side effect for having this integration we have to bundle and deliver to all the users a big amount of jars; instead this should be an optional (downloaded separately) component that only interested users should get (and these users will probably already have their own Birt setup). OFbiz should stay lighter and should delegate the decision about what reporting engine to use to the user. I suspect that, if the user community is really using this integration to build reports, we would get a lot of them contributed... and this is not happening.

> I cannot agree with the removal of these components, Birt integration and JCR (in the short term)
> 

Fair enough; we will see what others have to say on this subject as well. Then we will take the best decision for the community.

> Some other proposals:
> 1. I would like to push for more junit tests and use even this as a measure to keep a component in the system or not. (cobertura minimum percentage?)

This is a good idea indeed if the presence/lack of junit test will be used as an additional element for the decision; but it can't be the only one because we could have a component that has a lot of junit tests but for some reason is not a good fit for OFBiz (for example because its implementation doesn't follow best practices, or no one is willing to maintain it etc...); in this case it should be removed as well.

> 2. To have a lead committer appointed for every component in the system who will check incoming patches and will commit them, to relieve Jacques of some work.

I don't like very much this because it implies some sort of "ownership" over code.

> 3. List functions/tasks with every committer, if a committer does not have a function/task or is not active for a year, put him on the emeritus list, if he gets active again put him back as a committer on his request. This to get a real committers (and contributors, see next point) list.
> 4. Also list contributors who have a function/task assigned either for creating documents, reporting errors or supply patches, list the contributions he/she did so we can keep up if he/she could be nominated to be a committer.

These last 2 points are probably off topic here (please discuss them in another thread) but I will provide my quick feedback because they are interesting:
* I like the idea of point #4 for helping us to keep track of future candidates for being committers; we could also keep track of commit revisions where they patches have been submitted
* I don't see the need for such a formal process for #3: it may be interesting to formalize who is active (with commits or reviews etc...) and who is not but it is already quite evident from the lists because we are a small group; this would also add some unnecessary overhead on the community: keep track of contributions, vote to move them to emeritus (contact infra to revoke commit rights?), and back if they want to come back (contact infra to regrant commit rights?)
* when we talk about "contributions and commits" as a means to evaluate how much a contributor is helping the project then I would like to stress an important point, that was not considered until now: the contributions/commits must be inline with the current roadmap and priorities chosen by the community; otherwise, even if committer X is committing a huge number of code on a component she is working on for some personal interest, but not solicited by the community, then it would not be considered a "top contributor"

Thanks for your comments.

Kind regards,

Jacopo

> 
> Thanks again for your activity, keep up the good work!
> 
> Regards,
> Hans
> 
> 
> On 03/18/2012 04:10 PM, Jacopo Cappellato wrote:
>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>> 
>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>> 
>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>> 
>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>> And this is exactly what we have now:
>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>> 
>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>> 
>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>> 
>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>> 
>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>> 
>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>> 
>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>> * is this feature used by other code in the system?
>> * is the feature functional? or is it largely incomplete?
>> * is this an old component/code?
>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>> 
>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>> 
>> 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"
>> 
>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>> 
>> 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"
>> 
>> C) $OFBIZ_HOME/debian: move to "Attic"
>> 
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>> 
>> E) specialpurpose/workflow: move to "Attic"
>> 
>> F) specialpurpose/shark: move to "Attic"
>> 
>> G) specialpurpose/ofbizwebsite: move to "Attic"
>> 
>> 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"
>> 
>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>> 
>> J) framework/appserver: move to "Extras"
>> 
>> K) framework/jetty: move to "Extras" (or "Attic")
>> 
>> 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"
>> 
>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>> 
>> O) framework/documents: move the content to Wiki and then move to "Attic"
>> 
>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>> 
>> Q) framework/example and framework/exampleext: move to specialpurpose
>> 
>> Kind regards,
>> 
>> Jacopo
>> 
> 
> 

Re: Lose Weight Program for OFBiz

[Olivier Heintz <ho...@nereide.biz>]

Le 19/03/2012 13:12, Hans Bakker a écrit :
> Scott,
>
> I appreciate your reply , but this apache extra's stuff is not 
> working.....: the Apache extra's is now over one year old, in that 
> time there are 125 extra's for 84 projects..... I even counted all the 
> test and apple dirs.....most projects are empty and do not have any 
> extra's
>
> sorry i see moving out of special purpose components to extra's as a 
> big error.
>
> Your advantages below will not work because Apache extra will be not a 
> success. What is apache extra? A link screen to google projects which 
> have some link to a apache project. Good for single developers, not 
> good for us (Antwebsystems) because we rather use our own 
> infrastructure which is integrated with the OFBiz system scrum 
> component what is not possible with an external svn.
If we (the ofbiz community) gives the correct tools (plugin management, 
Continuous Integration, release publishing, ...) to works with OFBiz 
Extra and Apache-OFBiz,
1) company could work with their own infrastructure which could be 
integrated with Apache-OFBiz and OFBiz-Extra
2) it will be possible to have OOTB solution for specifics need
3) users can easily view what is working and so use choose and use it

ERP is really a good use case for Kernel and added features, and so it 
should work with Apache-OFBiz andd OFBiz-Extra
>
> Extra publicity? not really , we can publisize links in the ofbiz wiki 
> to our own repository just the same.
>
> Regards, Hans
>
> On 03/19/2012 05:32 PM, Scott Gray wrote:
>> Hi Hans,
>>
>> I don't want to argue the merits of removing specific portions of 
>> code/features/components but I think it's worth mentioning some of 
>> the benefits of moving features to Extras:
>> - Greater access to contributors, if someone is making regular 
>> quality contributions to a specific Extra then they can easily be 
>> granted commit access.  Easier for the contributor and no worry for 
>> the PMC that we have to grant access to the entire codebase (which in 
>> turn is better for the entire community)
>> - Moving something to Extras shouldn't be considered as a loss to 
>> OFBiz or to the community.  It is merely a means of streamlining and 
>> consolidating what is offered by OFBiz OOTB.  Personally I envision 
>> OFBiz Extras as potentially becoming a vibrant community in itself, 
>> if we seed that community with a decent set of add-on functionality 
>> then it's quite possible other people would start to do the same.  
>> Providing and managing an Extra for the community would bring a type 
>> of recognition that donating it directly to OFBiz never could.  For a 
>> company such as yours that likes to promote itself quite a bit it 
>> could actually work out to be an advantage for you.
>> - The benefits of a slimmer OFBiz really can't be understated, at the 
>> moment we have something like 7000+ services, I don't know about you 
>> but I'd be lucky to be able to describe what maybe 10-20% actually 
>> do.  The idea that you can download OFBiz, pop over to Extras and 
>> gran the things you actually need sounds super appealing to me.  Sure 
>> it's an extra step that needs to be taken but I don't think that 
>> outweighs that benefits of being able to run only what you need.
>> - New features for old releases.  With components existing outside of 
>> OFBiz, contributors could make newer versions of components 
>> compatible with older releases of OFBiz, essentially allowing what we 
>> don't currently.  If we can build a good community around Extras then 
>> I think we could see some amazing things happen in this regard.  
>> People could be empowered to do things that would never be accepted 
>> into OFBiz but would still be useful to a large number of people.  
>> Perhaps someone wants to develop Catalog Manager 2.0 using Apache 
>> Wicket or Apache Click or some other UI framework, they could do that 
>> and know that it will have an audience because we'll be actively 
>> endorsing the Extras community as a place to go for additional 
>> functionality.
>>
>> Anyway, I'm not arguing any of your points, I just want to make it 
>> clear to you and everyone else that I see this as an opportunity to 
>> make more features available for OFBiz rather than any attempt to 
>> take out the trash (that's the Attic's job).
>>
>> Regards
>> Scott
>>
>> On 19/03/2012, at 9:05 PM, Hans Bakker wrote:
>>
>>> Hi Jacopo,
>>>
>>> Thank you for the effort you spend with OFBiz the last few months. I 
>>> generally agree that sure we have to cut the dead wood in the 
>>> system. Components and functions which are not used or only halfway 
>>> implemented sure, sounds like a good idea to move them out.
>>>
>>> However the reasons you list as 'high maintenance' i do not agree 
>>> with. Only with file changes there is work, otherwise it is pretty 
>>> limited. Removing half baked code sure, lets remove it.
>>>
>>> The 'not complete' reasons do not apply to several applications and 
>>> functions you want to remove because they are complete, like asset 
>>> maintenance, LDAP, POS, e-commerce, cmssite(demo for the content 
>>> component perhaps better to integrate it with ecommerce), projectmgr 
>>> and scrum. Also moving the JCR function out is not a good idea 
>>> however when not improved in the next few months using the content 
>>> manager, i would agree to a removal.
>>> Then I was even more surprised, because reporting is a pretty weak 
>>> point in OFBiz, to remove the Birt integration and data warehouse 
>>> entities.
>>> I cannot agree with the removal of these components, Birt 
>>> integration and JCR (in the short term)
>>>
>>> Some other proposals:
>>> 1. I would like to push for more junit tests and use even this as a 
>>> measure to keep a component in the system or not. (cobertura minimum 
>>> percentage?)
>>> 2. To have a lead committer appointed for every component in the 
>>> system who will check incoming patches and will commit them, to 
>>> relieve Jacques of some work.
>>> 3. List functions/tasks with every committer, if a committer does 
>>> not have a function/task or is not active for a year, put him on the 
>>> emeritus list, if he gets active again put him back as a committer 
>>> on his request. This to get a real committers (and contributors, see 
>>> next point) list.
>>> 4. Also list contributors who have a function/task assigned either 
>>> for creating documents, reporting errors or supply patches, list the 
>>> contributions he/she did so we can keep up if he/she could be 
>>> nominated to be a committer.
>>>
>>> Thanks again for your activity, keep up the good work!
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>> On 03/18/2012 04:10 PM, Jacopo Cappellato wrote:
>>>> In the last period the OFBiz project has grown a lot in shape: the 
>>>> implicitly accepted (or tolerated) strategy operated by the active 
>>>> committers was that the more features you could add to the official 
>>>> repository the better was: you make happy the contributors, making 
>>>> them feel like they are a part of something, and each committer 
>>>> could manage the code implemented for his/her own projects directly 
>>>> in the OFBiz codebase.
>>>>
>>>> We operated under the concept that, since the code if "free" and 
>>>> the author (committer or not) is willing to contribute it, then no 
>>>> one should/could complain if it is added to the repository, if it 
>>>> doesn't cause immediate problems to others; all in all it is an 
>>>> additional feature that may be used by someone else in the future 
>>>> or if not would simply stay there without causing any harm.
>>>> Following this strategy we got a lot of code like for example 
>>>> Webslinger, seleniumxml, debian packages, all sort of 
>>>> specialpurpose applications etc...
>>>>
>>>> Since there was not a central and agreed upon roadmap, no one could 
>>>> really state that a contribution was not a good fit for the 
>>>> project: each and every committer could add what, in his own 
>>>> personal vision, was good for the project.
>>>>
>>>> The wrong assumption is that, since the code if "free" then it 
>>>> doesn't harm to include it. This is completely *wrong*: the code is 
>>>> not *free* at all because as soon as you add it to the repository 
>>>> then you add a future cost to the community: you all know that in 
>>>> the software industry the cost to maintain a piece of code is by 
>>>> far greater than the cost to write it; and you *have* to maintain 
>>>> the code unless you want to have and distribute stale code.
>>>> And this is exactly what we have now:
>>>> * high costs to maintain the code (e.g. I recently spent a lot of 
>>>> hours to remove the Webslinger component)
>>>> * stale/unused/half baked code that causes confusion and bad 
>>>> impression to user evaluating the quality of our product
>>>>
>>>> The message to all the committers is: when you add code to the 
>>>> repository, you are asking the community to take care of its 
>>>> maintenance costs forever. So please, add new code only when it is 
>>>> really beneficial to the project and to a large audience of 
>>>> committers and users.
>>>>
>>>> It is like feeding a wild animal at the zoo with chips: everyone 
>>>> knows it is bad for its health but when you are there it is so nice 
>>>> when it picks the food from your own hands and you cannot resist 
>>>> and have to feed it.
>>>>
>>>> OFBiz is now suffering from serious weight issues: the committers 
>>>> community is having an hard time to maintain the huge codebase, it 
>>>> is difficult to keep track of all the features in the system etc...
>>>>
>>>> I think it is important to start a new phase of the project and 
>>>> focus our energy in cleanup and consolidation of what we have. One 
>>>> step in this direction is for OFBiz to lose weight.
>>>>
>>>> In order to get the ball rolling and focus on some concrete tasks I 
>>>> am providing here some examples of stuff that I would like to see 
>>>> removed from the project.
>>>>
>>>> IMPORTANT: Please consider that the list is not based on what I 
>>>> think the perfect framework should be (so PLEASE do not reply 
>>>> stating what your ideal framework should have), but simply on the 
>>>> following considerations:
>>>> * can the component be easily removed by the project? is it 
>>>> independent and can live outside as a plugin?
>>>> * do we need all this custom code? can't we find a simpler, lighter 
>>>> and better way to implement this?
>>>> * is this feature used by other code in the system?
>>>> * is the feature functional? or is it largely incomplete?
>>>> * is this an old component/code?
>>>> * is this used by a lot of persons? (this is tricky to decide but 
>>>> you can get a feeling of it by reading the mailing lists, 
>>>> considering commit activity, the status of the feature etc...)
>>>>
>>>> DISCLAIMER: I know it will be a painful decision because each of us 
>>>> reading this will have a connection with some of the code listed 
>>>> below: several hours spent on it, great ideas that never came to a 
>>>> finished plan; in fact I feel the same for a few of the things in 
>>>> the list.... there are great ideas that didn't come to a 
>>>> finalization... it doesn't mean that moving them out of the project 
>>>> will kill them and this may actually help to get more visibility 
>>>> and different user group; so please when you will read it... think 
>>>> to the greater good of the community.
>>>>
>>>> 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"
>>>>
>>>> And now (drums)..... THE LIST - PART 1(but this is really a very 
>>>> first pass only, PART 2 will come soon with more granular - 
>>>> subcomponent - details):
>>>>
>>>> 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"
>>>>
>>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>>>
>>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>>>
>>>> E) specialpurpose/workflow: move to "Attic"
>>>>
>>>> F) specialpurpose/shark: move to "Attic"
>>>>
>>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>>
>>>> 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"
>>>>
>>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of 
>>>> them to "Extras"; keep just one (or two)
>>>>
>>>> J) framework/appserver: move to "Extras"
>>>>
>>>> K) framework/jetty: move to "Extras" (or "Attic")
>>>>
>>>> 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"
>>>>
>>>> N) framework/jcr: move back into the Jackrabbit branch until the 
>>>> work is completed and can replace the existing "content framework"
>>>>
>>>> O) framework/documents: move the content to Wiki and then move to 
>>>> "Attic"
>>>>
>>>> P) framework/datafile: (who is currently using it?) move to 
>>>> "Extras" or "Attic"; we could replace it with commons-csv or 
>>>> similar tool
>>>>
>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>>
>>>> Kind regards,
>>>>
>>>> Jacopo
>>>>
>
>
>

Re: Lose Weight Program for OFBiz

[Hans Bakker <ma...@antwebsystems.com>]

Scott,

I appreciate your reply , but this apache extra's stuff is not 
working.....: the Apache extra's is now over one year old, in that time 
there are 125 extra's for 84 projects..... I even counted all the test 
and apple dirs.....most projects are empty and do not have any extra's

sorry i see moving out of special purpose components to extra's as a big 
error.

Your advantages below will not work because Apache extra will be not a 
success. What is apache extra? A link screen to google projects which 
have some link to a apache project. Good for single developers, not good 
for us (Antwebsystems) because we rather use our own infrastructure 
which is integrated with the OFBiz system scrum component what is not 
possible with an external svn.

Extra publicity? not really , we can publisize links in the ofbiz wiki 
to our own repository just the same.

Regards, Hans

On 03/19/2012 05:32 PM, Scott Gray wrote:
> Hi Hans,
>
> I don't want to argue the merits of removing specific portions of code/features/components but I think it's worth mentioning some of the benefits of moving features to Extras:
> - Greater access to contributors, if someone is making regular quality contributions to a specific Extra then they can easily be granted commit access.  Easier for the contributor and no worry for the PMC that we have to grant access to the entire codebase (which in turn is better for the entire community)
> - Moving something to Extras shouldn't be considered as a loss to OFBiz or to the community.  It is merely a means of streamlining and consolidating what is offered by OFBiz OOTB.  Personally I envision OFBiz Extras as potentially becoming a vibrant community in itself, if we seed that community with a decent set of add-on functionality then it's quite possible other people would start to do the same.  Providing and managing an Extra for the community would bring a type of recognition that donating it directly to OFBiz never could.  For a company such as yours that likes to promote itself quite a bit it could actually work out to be an advantage for you.
> - The benefits of a slimmer OFBiz really can't be understated, at the moment we have something like 7000+ services, I don't know about you but I'd be lucky to be able to describe what maybe 10-20% actually do.  The idea that you can download OFBiz, pop over to Extras and gran the things you actually need sounds super appealing to me.  Sure it's an extra step that needs to be taken but I don't think that outweighs that benefits of being able to run only what you need.
> - New features for old releases.  With components existing outside of OFBiz, contributors could make newer versions of components compatible with older releases of OFBiz, essentially allowing what we don't currently.  If we can build a good community around Extras then I think we could see some amazing things happen in this regard.  People could be empowered to do things that would never be accepted into OFBiz but would still be useful to a large number of people.  Perhaps someone wants to develop Catalog Manager 2.0 using Apache Wicket or Apache Click or some other UI framework, they could do that and know that it will have an audience because we'll be actively endorsing the Extras community as a place to go for additional functionality.
>
> Anyway, I'm not arguing any of your points, I just want to make it clear to you and everyone else that I see this as an opportunity to make more features available for OFBiz rather than any attempt to take out the trash (that's the Attic's job).
>
> Regards
> Scott
>
> On 19/03/2012, at 9:05 PM, Hans Bakker wrote:
>
>> Hi Jacopo,
>>
>> Thank you for the effort you spend with OFBiz the last few months. I generally agree that sure we have to cut the dead wood in the system. Components and functions which are not used or only halfway implemented sure, sounds like a good idea to move them out.
>>
>> However the reasons you list as 'high maintenance' i do not agree with. Only with file changes there is work, otherwise it is pretty limited. Removing half baked code sure, lets remove it.
>>
>> The 'not complete' reasons do not apply to several applications and functions you want to remove because they are complete, like asset maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component perhaps better to integrate it with ecommerce), projectmgr and scrum. Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal.
>> Then I was even more surprised, because reporting is a pretty weak point in OFBiz, to remove the Birt integration and data warehouse entities.
>> I cannot agree with the removal of these components, Birt integration and JCR (in the short term)
>>
>> Some other proposals:
>> 1. I would like to push for more junit tests and use even this as a measure to keep a component in the system or not. (cobertura minimum percentage?)
>> 2. To have a lead committer appointed for every component in the system who will check incoming patches and will commit them, to relieve Jacques of some work.
>> 3. List functions/tasks with every committer, if a committer does not have a function/task or is not active for a year, put him on the emeritus list, if he gets active again put him back as a committer on his request. This to get a real committers (and contributors, see next point) list.
>> 4. Also list contributors who have a function/task assigned either for creating documents, reporting errors or supply patches, list the contributions he/she did so we can keep up if he/she could be nominated to be a committer.
>>
>> Thanks again for your activity, keep up the good work!
>>
>> Regards,
>> Hans
>>
>>
>> On 03/18/2012 04:10 PM, Jacopo Cappellato wrote:
>>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>>>
>>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>>
>>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>>>
>>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>>> And this is exactly what we have now:
>>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>>>
>>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>>>
>>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>>>
>>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>>>
>>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>>>
>>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>>>
>>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>>> * is this feature used by other code in the system?
>>> * is the feature functional? or is it largely incomplete?
>>> * is this an old component/code?
>>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>>>
>>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>>>
>>> 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"
>>>
>>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>>>
>>> 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"
>>>
>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>>
>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>>
>>> E) specialpurpose/workflow: move to "Attic"
>>>
>>> F) specialpurpose/shark: move to "Attic"
>>>
>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>
>>> 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"
>>>
>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>>
>>> J) framework/appserver: move to "Extras"
>>>
>>> K) framework/jetty: move to "Extras" (or "Attic")
>>>
>>> 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"
>>>
>>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>>>
>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>>
>>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>>>
>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>
>>> Kind regards,
>>>
>>> Jacopo
>>>

Re: Lose Weight Program for OFBiz

[Jacques Le Roux <ja...@les7arts.com>]

I want also to emphasize that having many possible syntaxes in <use-when, <set, etc. is not a plus for me. We could make it possible 
but have a single way in OFBiz OOTB. I guess there are no needs to argue about...

Jacques

From: "Jacques Le Roux" <ja...@les7arts.com>
>A point I'd like to emphasize: before moving things out we should check all related pending Jiras
>
> Jacques 

Re: Lose Weight Program for OFBiz

[Jacques Le Roux <ja...@les7arts.com>]

A point I'd like to emphasize: before moving things out we should check all related pending Jiras

Jacques

Re: Lose Weight Program for OFBiz

[Scott Gray <sc...@hotwaxmedia.com>]

Hi Hans,

I don't want to argue the merits of removing specific portions of code/features/components but I think it's worth mentioning some of the benefits of moving features to Extras:
- Greater access to contributors, if someone is making regular quality contributions to a specific Extra then they can easily be granted commit access.  Easier for the contributor and no worry for the PMC that we have to grant access to the entire codebase (which in turn is better for the entire community)
- Moving something to Extras shouldn't be considered as a loss to OFBiz or to the community.  It is merely a means of streamlining and consolidating what is offered by OFBiz OOTB.  Personally I envision OFBiz Extras as potentially becoming a vibrant community in itself, if we seed that community with a decent set of add-on functionality then it's quite possible other people would start to do the same.  Providing and managing an Extra for the community would bring a type of recognition that donating it directly to OFBiz never could.  For a company such as yours that likes to promote itself quite a bit it could actually work out to be an advantage for you.
- The benefits of a slimmer OFBiz really can't be understated, at the moment we have something like 7000+ services, I don't know about you but I'd be lucky to be able to describe what maybe 10-20% actually do.  The idea that you can download OFBiz, pop over to Extras and gran the things you actually need sounds super appealing to me.  Sure it's an extra step that needs to be taken but I don't think that outweighs that benefits of being able to run only what you need.
- New features for old releases.  With components existing outside of OFBiz, contributors could make newer versions of components compatible with older releases of OFBiz, essentially allowing what we don't currently.  If we can build a good community around Extras then I think we could see some amazing things happen in this regard.  People could be empowered to do things that would never be accepted into OFBiz but would still be useful to a large number of people.  Perhaps someone wants to develop Catalog Manager 2.0 using Apache Wicket or Apache Click or some other UI framework, they could do that and know that it will have an audience because we'll be actively endorsing the Extras community as a place to go for additional functionality.

Anyway, I'm not arguing any of your points, I just want to make it clear to you and everyone else that I see this as an opportunity to make more features available for OFBiz rather than any attempt to take out the trash (that's the Attic's job).

Regards
Scott

On 19/03/2012, at 9:05 PM, Hans Bakker wrote:

> Hi Jacopo,
> 
> Thank you for the effort you spend with OFBiz the last few months. I generally agree that sure we have to cut the dead wood in the system. Components and functions which are not used or only halfway implemented sure, sounds like a good idea to move them out.
> 
> However the reasons you list as 'high maintenance' i do not agree with. Only with file changes there is work, otherwise it is pretty limited. Removing half baked code sure, lets remove it.
> 
> The 'not complete' reasons do not apply to several applications and functions you want to remove because they are complete, like asset maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component perhaps better to integrate it with ecommerce), projectmgr and scrum. Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal.
> Then I was even more surprised, because reporting is a pretty weak point in OFBiz, to remove the Birt integration and data warehouse entities.
> I cannot agree with the removal of these components, Birt integration and JCR (in the short term)
> 
> Some other proposals:
> 1. I would like to push for more junit tests and use even this as a measure to keep a component in the system or not. (cobertura minimum percentage?)
> 2. To have a lead committer appointed for every component in the system who will check incoming patches and will commit them, to relieve Jacques of some work.
> 3. List functions/tasks with every committer, if a committer does not have a function/task or is not active for a year, put him on the emeritus list, if he gets active again put him back as a committer on his request. This to get a real committers (and contributors, see next point) list.
> 4. Also list contributors who have a function/task assigned either for creating documents, reporting errors or supply patches, list the contributions he/she did so we can keep up if he/she could be nominated to be a committer.
> 
> Thanks again for your activity, keep up the good work!
> 
> Regards,
> Hans
> 
> 
> On 03/18/2012 04:10 PM, Jacopo Cappellato wrote:
>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>> 
>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>> 
>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>> 
>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>> And this is exactly what we have now:
>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>> 
>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>> 
>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>> 
>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>> 
>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>> 
>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>> 
>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>> * is this feature used by other code in the system?
>> * is the feature functional? or is it largely incomplete?
>> * is this an old component/code?
>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>> 
>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>> 
>> 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"
>> 
>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>> 
>> 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"
>> 
>> C) $OFBIZ_HOME/debian: move to "Attic"
>> 
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>> 
>> E) specialpurpose/workflow: move to "Attic"
>> 
>> F) specialpurpose/shark: move to "Attic"
>> 
>> G) specialpurpose/ofbizwebsite: move to "Attic"
>> 
>> 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"
>> 
>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>> 
>> J) framework/appserver: move to "Extras"
>> 
>> K) framework/jetty: move to "Extras" (or "Attic")
>> 
>> 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"
>> 
>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>> 
>> O) framework/documents: move the content to Wiki and then move to "Attic"
>> 
>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>> 
>> Q) framework/example and framework/exampleext: move to specialpurpose
>> 
>> Kind regards,
>> 
>> Jacopo
>> 
> 
> 

Re: Lose Weight Program for OFBiz

[Hans Bakker <h....@antwebsystems.com>]

Hi Jacopo,

Thank you for the effort you spend with OFBiz the last few months. I 
generally agree that sure we have to cut the dead wood in the system. 
Components and functions which are not used or only halfway implemented 
sure, sounds like a good idea to move them out.

However the reasons you list as 'high maintenance' i do not agree with. 
Only with file changes there is work, otherwise it is pretty limited. 
Removing half baked code sure, lets remove it.

The 'not complete' reasons do not apply to several applications and 
functions you want to remove because they are complete, like asset 
maintenance, LDAP, POS, e-commerce, cmssite(demo for the content 
component perhaps better to integrate it with ecommerce), projectmgr and 
scrum. Also moving the JCR function out is not a good idea however when 
not improved in the next few months using the content manager, i would 
agree to a removal.
Then I was even more surprised, because reporting is a pretty weak point 
in OFBiz, to remove the Birt integration and data warehouse entities.
I cannot agree with the removal of these components, Birt integration 
and JCR (in the short term)

Some other proposals:
1. I would like to push for more junit tests and use even this as a 
measure to keep a component in the system or not. (cobertura minimum 
percentage?)
2. To have a lead committer appointed for every component in the system 
who will check incoming patches and will commit them, to relieve Jacques 
of some work.
3. List functions/tasks with every committer, if a committer does not 
have a function/task or is not active for a year, put him on the 
emeritus list, if he gets active again put him back as a committer on 
his request. This to get a real committers (and contributors, see next 
point) list.
4. Also list contributors who have a function/task assigned either for 
creating documents, reporting errors or supply patches, list the 
contributions he/she did so we can keep up if he/she could be nominated 
to be a committer.

Thanks again for your activity, keep up the good work!

Regards,
Hans


On 03/18/2012 04:10 PM, Jacopo Cappellato wrote:
> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>
> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>
> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>
> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
> And this is exactly what we have now:
> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>
> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>
> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>
> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>
> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>
> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>
> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
> * is this feature used by other code in the system?
> * is the feature functional? or is it largely incomplete?
> * is this an old component/code?
> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>
> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>
> 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"
>
> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>
> 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"
>
> C) $OFBIZ_HOME/debian: move to "Attic"
>
> D) the seleniumxml code in framework/testtools: move to "Attic"
>
> E) specialpurpose/workflow: move to "Attic"
>
> F) specialpurpose/shark: move to "Attic"
>
> G) specialpurpose/ofbizwebsite: move to "Attic"
>
> 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"
>
> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>
> J) framework/appserver: move to "Extras"
>
> K) framework/jetty: move to "Extras" (or "Attic")
>
> 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"
>
> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>
> O) framework/documents: move the content to Wiki and then move to "Attic"
>
> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>
> Q) framework/example and framework/exampleext: move to specialpurpose
>
> Kind regards,
>
> Jacopo
>

Re: Lose Weight Program for OFBiz

[Pierre Smits <pi...@gmail.com>]

It seems weird to keep a 'demo application' in the framework, purely to
facilitate developers. It adds no value to using ofbiz in production. So it
should be removable from the framework and and self-contained (no
dependencies from other applications).

Op 18 maart 2012 12:16 schreef <ad...@sandglass-software.com> het
volgende:

> I think Example should stay in the framework, but get rid of all of the
> "showroom" stuff that has been added to it. In other words, keep it and
> return it to its original purpose - a very basic component for new users to
> understand OFBiz.
>
> I use datafile to connect legacy systems to OFBiz.
>
> I agree that specialpurpose should be slimmed down, but we should retain
> one or two components to demonstrate the concept of reusing artifacts to
> create custom applications.
>
> -Adrian
>
>
> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>
> >:
>
>  In the last period the OFBiz project has grown a lot in shape: the
>> implicitly accepted (or tolerated) strategy operated by the active
>> committers was that the more features you could add to the official
>> repository the better was: you make happy the contributors, making them
>> feel like they are a part of something, and each committer could manage the
>> code implemented for his/her own projects directly in the OFBiz codebase.
>>
>> We operated under the concept that, since the code if "free" and the
>> author (committer or not) is willing to contribute it, then no one
>> should/could complain if it is added to the repository, if it doesn't cause
>> immediate problems to others; all in all it is an additional feature that
>> may be used by someone else in the future or if not would simply stay there
>> without causing any harm.
>> Following this strategy we got a lot of code like for example Webslinger,
>> seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>
>> Since there was not a central and agreed upon roadmap, no one could
>> really state that a contribution was not a good fit for the project: each
>> and every committer could add what, in his own personal vision, was good
>> for the project.
>>
>> The wrong assumption is that, since the code if "free" then it doesn't
>> harm to include it. This is completely *wrong*: the code is not *free* at
>> all because as soon as you add it to the repository then you add a future
>> cost to the community: you all know that in the software industry the cost
>> to maintain a piece of code is by far greater than the cost to write it;
>> and you *have* to maintain the code unless you want to have and distribute
>> stale code.
>> And this is exactly what we have now:
>> * high costs to maintain the code (e.g. I recently spent a lot of hours
>> to remove the Webslinger component)
>> * stale/unused/half baked code that causes confusion and bad impression
>> to user evaluating the quality of our product
>>
>> The message to all the committers is: when you add code to the
>> repository, you are asking the community to take care of its maintenance
>> costs forever. So please, add new code only when it is really beneficial to
>> the project and to a large audience of committers and users.
>>
>> It is like feeding a wild animal at the zoo with chips: everyone knows it
>> is bad for its health but when you are there it is so nice when it picks
>> the food from your own hands and you cannot resist and have to feed it.
>>
>> OFBiz is now suffering from serious weight issues: the committers
>> community is having an hard time to maintain the huge codebase, it is
>> difficult to keep track of all the features in the system etc...
>>
>> I think it is important to start a new phase of the project and focus our
>> energy in cleanup and consolidation of what we have. One step in this
>> direction is for OFBiz to lose weight.
>>
>> In order to get the ball rolling and focus on some concrete tasks I am
>> providing here some examples of stuff that I would like to see removed from
>> the project.
>>
>> IMPORTANT: Please consider that the list is not based on what I think the
>> perfect framework should be (so PLEASE do not reply stating what your ideal
>> framework should have), but simply on the following considerations:
>> * can the component be easily removed by the project? is it independent
>> and can live outside as a plugin?
>> * do we need all this custom code? can't we find a simpler, lighter and
>> better way to implement this?
>> * is this feature used by other code in the system?
>> * is the feature functional? or is it largely incomplete?
>> * is this an old component/code?
>> * is this used by a lot of persons? (this is tricky to decide but you can
>> get a feeling of it by reading the mailing lists, considering commit
>> activity, the status of the feature etc...)
>>
>> DISCLAIMER: I know it will be a painful decision because each of us
>> reading this will have a connection with some of the code listed below:
>> several hours spent on it, great ideas that never came to a finished plan;
>> in fact I feel the same for a few of the things in the list.... there are
>> great ideas that didn't come to a finalization... it doesn't mean that
>> moving them out of the project will kill them and this may actually help to
>> get more visibility and different user group; so please when you will read
>> it... think to the greater good of the community.
>>
>> 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"
>>
>> And now (drums)..... THE LIST - PART 1(but this is really a very first
>> pass only, PART 2 will come soon with more granular - subcomponent -
>> details):
>>
>> 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"
>>
>> C) $OFBIZ_HOME/debian: move to "Attic"
>>
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>
>> E) specialpurpose/workflow: move to "Attic"
>>
>> F) specialpurpose/shark: move to "Attic"
>>
>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>
>> 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"
>>
>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them
>> to "Extras"; keep just one (or two)
>>
>> J) framework/appserver: move to "Extras"
>>
>> K) framework/jetty: move to "Extras" (or "Attic")
>>
>> 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"
>>
>> N) framework/jcr: move back into the Jackrabbit branch until the work is
>> completed and can replace the existing "content framework"
>>
>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>
>> P) framework/datafile: (who is currently using it?) move to "Extras" or
>> "Attic"; we could replace it with commons-csv or similar tool
>>
>> Q) framework/example and framework/exampleext: move to specialpurpose
>>
>> Kind regards,
>>
>> Jacopo
>>
>>
>>
>
>
>

Re: Lose Weight Program for OFBiz

[Jacques Le Roux <ja...@les7arts.com>]

From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> On Mar 18, 2012, at 1:05 PM, Jacques Le Roux wrote:
>
>>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>
>> So get rid of the online help also?
>
> We can keep the online help (we can maybe review the implementation of the mechanism... and the content itself really needs some 
> serious review) if there is a general interest; however it shouldn't stay in the framework... commonext would be a better fit (and 
> yes I think it is acceptable to not have the online help for webtools and example, if example will stay in the framework).
>
> Jacopo

excerpts:
>we can maybe review the implementation of the mechanism...

Yes there are documents folders also under some framework components...

>and the content itself really needs some serious review

That's the trap with help, comments in codes, etc. : it really needs to stay up to date...


> I think it is acceptable to not have the online help for webtools and example, if example will stay in the framework

I think there are none anyway (at least no help button there)

Jacques 

Re: Lose Weight Program for OFBiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On Mar 18, 2012, at 1:05 PM, Jacques Le Roux wrote:

>>> O) framework/documents: move the content to Wiki and then move to "Attic"
> 
> So get rid of the online help also?

We can keep the online help (we can maybe review the implementation of the mechanism... and the content itself really needs some serious review) if there is a general interest; however it shouldn't stay in the framework... commonext would be a better fit (and yes I think it is acceptable to not have the online help for webtools and example, if example will stay in the framework).

Jacopo

Re: Lose Weight Program for OFBiz

[Jacques Le Roux <ja...@les7arts.com>]

From: "Olivier Heintz" <ho...@nereide.biz>
> Le 18/03/2012 14:43, adrian.crum@sandglass-software.com a écrit :
>> Here is what I am suggesting:
>>
>> 1. Keep the Example component in the framework folder.
>> 2. Return the Example component to its original purpose: A stripped down, very basic application for a new user to evaluate and 
>> understand. That would require removing all of the things that have been added that have nothing to do with the original 
>> purpose - like Ajax examples, form widgets examples, portal page examples, JCR examples, etc.
> In my understanding, example contain a example of each developing current valid method to help new developer to see an example of 
> each.
> If it's not in example, these examples  should be move to exampleext in extra

I'd prefer to keep exampleext (or whatever it's names) in specialpurpose rather for 2 reasons
1. Easy access for new users but not bloating framework
2. I sometimes use the form widget page in demo trunk when testing things, having it in specialpurpose would be easier than extra

Jacques

>>
>> -Adrian
>>
>>
>> Quoting Jacques Le Roux <ja...@les7arts.com>:
>>
>>> From: <ad...@sandglass-software.com>
>>>> Quoting Jacques Le Roux <ja...@les7arts.com>:
>>>>
>>>>> Thanks for the proposition Jacopo,
>>>>>
>>>>> Inline...
>>>>>
>>>>> From: <ad...@sandglass-software.com>
>>>>>> I think Example should stay in the framework, but get rid of all of
>>>>>> the "showroom" stuff that has been added to it. In other words,
>>>>>> keep  it and return it to its original purpose - a very basic
>>>>>> component for  new users to understand OFBiz.
>>>>>
>>>>> I agree notably the forms page
>>>>> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
>>>>
>>>> Form widget examples, Ajax examples, Portal examples, JCR examples,
>>>> etc. All of it. This was supposed to be a stripped down application
>>>> that would not overwhelm a new user.
>>>
>>> I think I misread and thought Jacopo suggested to put them in Extra. Finally, no pb with me as long as they stay in 
>>> specialpurpose: ie users have an obvious acces to it.
>>>
>>> So you would only keep the main page (ie https://demo-trunk.ofbiz.apache.org/example/control/main)?
>>> Why not put all in specialpurpose? It would be more clear than having things separated.
>>>
>>> Jacques
>>>
>>>> -Adrian
>>>>
>>>>
>>>
>>
>>
>>
>>
> 

Re: Lose Weight Program for OFBiz

[Olivier Heintz <ho...@nereide.biz>]

Le 18/03/2012 14:43, adrian.crum@sandglass-software.com a écrit :
> Here is what I am suggesting:
>
> 1. Keep the Example component in the framework folder.
> 2. Return the Example component to its original purpose: A stripped 
> down, very basic application for a new user to evaluate and 
> understand. That would require removing all of the things that have 
> been added that have nothing to do with the original purpose - like 
> Ajax examples, form widgets examples, portal page examples, JCR 
> examples, etc.
In my understanding, example contain a example of each developing 
current valid method to help new developer to see an example of each.
If it's not in example, these examples  should be move to exampleext in 
extra

>
> -Adrian
>
>
> Quoting Jacques Le Roux <ja...@les7arts.com>:
>
>> From: <ad...@sandglass-software.com>
>>> Quoting Jacques Le Roux <ja...@les7arts.com>:
>>>
>>>> Thanks for the proposition Jacopo,
>>>>
>>>> Inline...
>>>>
>>>> From: <ad...@sandglass-software.com>
>>>>> I think Example should stay in the framework, but get rid of all of
>>>>> the "showroom" stuff that has been added to it. In other words,
>>>>> keep  it and return it to its original purpose - a very basic
>>>>> component for  new users to understand OFBiz.
>>>>
>>>> I agree notably the forms page
>>>> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
>>>
>>> Form widget examples, Ajax examples, Portal examples, JCR examples,
>>> etc. All of it. This was supposed to be a stripped down application
>>> that would not overwhelm a new user.
>>
>> I think I misread and thought Jacopo suggested to put them in Extra. 
>> Finally, no pb with me as long as they stay in specialpurpose: ie 
>> users have an obvious acces to it.
>>
>> So you would only keep the main page (ie 
>> https://demo-trunk.ofbiz.apache.org/example/control/main)?
>> Why not put all in specialpurpose? It would be more clear than having 
>> things separated.
>>
>> Jacques
>>
>>> -Adrian
>>>
>>>
>>
>
>
>
>

Re: Lose Weight Program for OFBiz

[Mansour Al Akeel <ma...@gmail.com>]

Jacopo,
thank you for opening this subject. I agree with you on everything.
I started few days ago, cleaning ofbiz on my local machine
restructuring as I go. I am new to the internals of the framework, and
doing this as an exercise.

Stuck on the few things but that's another post. The bottom line, I
agree with you about cleaning and losing some weight.

and by the way, thank you for removing Webslinger.


On Sun, Mar 18, 2012 at 9:43 AM,  <ad...@sandglass-software.com> wrote:
> Here is what I am suggesting:
>
> 1. Keep the Example component in the framework folder.
> 2. Return the Example component to its original purpose: A stripped down,
> very basic application for a new user to evaluate and understand. That would
> require removing all of the things that have been added that have nothing to
> do with the original purpose - like Ajax examples, form widgets examples,
> portal page examples, JCR examples, etc.
>
> -Adrian
>
>
>
> Quoting Jacques Le Roux <ja...@les7arts.com>:
>
>> From: <ad...@sandglass-software.com>
>>>
>>> Quoting Jacques Le Roux <ja...@les7arts.com>:
>>>
>>>> Thanks for the proposition Jacopo,
>>>>
>>>> Inline...
>>>>
>>>> From: <ad...@sandglass-software.com>
>>>>>
>>>>> I think Example should stay in the framework, but get rid of all of
>>>>> the "showroom" stuff that has been added to it. In other words,
>>>>> keep  it and return it to its original purpose - a very basic
>>>>> component for  new users to understand OFBiz.
>>>>
>>>>
>>>> I agree notably the forms page
>>>> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
>>>
>>>
>>> Form widget examples, Ajax examples, Portal examples, JCR examples,
>>> etc. All of it. This was supposed to be a stripped down application
>>> that would not overwhelm a new user.
>>
>>
>> I think I misread and thought Jacopo suggested to put them in Extra.
>> Finally, no pb with me as long as they stay in specialpurpose: ie users have
>> an obvious acces to it.
>>
>> So you would only keep the main page (ie
>> https://demo-trunk.ofbiz.apache.org/example/control/main)?
>> Why not put all in specialpurpose? It would be more clear than having
>> things separated.
>>
>> Jacques
>>
>>> -Adrian
>>>
>>>
>>
>
>
>

Re: Lose Weight Program for OFBiz

[ad...@sandglass-software.com]

Here is what I am suggesting:

1. Keep the Example component in the framework folder.
2. Return the Example component to its original purpose: A stripped  
down, very basic application for a new user to evaluate and  
understand. That would require removing all of the things that have  
been added that have nothing to do with the original purpose - like  
Ajax examples, form widgets examples, portal page examples, JCR  
examples, etc.

-Adrian


Quoting Jacques Le Roux <ja...@les7arts.com>:

> From: <ad...@sandglass-software.com>
>> Quoting Jacques Le Roux <ja...@les7arts.com>:
>>
>>> Thanks for the proposition Jacopo,
>>>
>>> Inline...
>>>
>>> From: <ad...@sandglass-software.com>
>>>> I think Example should stay in the framework, but get rid of all of
>>>> the "showroom" stuff that has been added to it. In other words,
>>>> keep  it and return it to its original purpose - a very basic
>>>> component for  new users to understand OFBiz.
>>>
>>> I agree notably the forms page
>>> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
>>
>> Form widget examples, Ajax examples, Portal examples, JCR examples,
>> etc. All of it. This was supposed to be a stripped down application
>> that would not overwhelm a new user.
>
> I think I misread and thought Jacopo suggested to put them in Extra.  
> Finally, no pb with me as long as they stay in specialpurpose: ie  
> users have an obvious acces to it.
>
> So you would only keep the main page (ie  
> https://demo-trunk.ofbiz.apache.org/example/control/main)?
> Why not put all in specialpurpose? It would be more clear than  
> having things separated.
>
> Jacques
>
>> -Adrian
>>
>>
>

Re: Lose Weight Program for OFBiz

[Jacques Le Roux <ja...@les7arts.com>]

From: <ad...@sandglass-software.com>
> Quoting Jacques Le Roux <ja...@les7arts.com>:
>
>> Thanks for the proposition Jacopo,
>>
>> Inline...
>>
>> From: <ad...@sandglass-software.com>
>>> I think Example should stay in the framework, but get rid of all of
>>>  the "showroom" stuff that has been added to it. In other words,
>>> keep  it and return it to its original purpose - a very basic
>>> component for  new users to understand OFBiz.
>>
>> I agree notably the forms page
>> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
>
> Form widget examples, Ajax examples, Portal examples, JCR examples,
> etc. All of it. This was supposed to be a stripped down application
> that would not overwhelm a new user.

I think I misread and thought Jacopo suggested to put them in Extra. Finally, no pb with me as long as they stay in specialpurpose: 
ie users have an obvious acces to it.

So you would only keep the main page (ie https://demo-trunk.ofbiz.apache.org/example/control/main)?
Why not put all in specialpurpose? It would be more clear than having things separated.

Jacques

> -Adrian
>
> 

Re: Lose Weight Program for OFBiz

[ad...@sandglass-software.com]

Quoting Jacques Le Roux <ja...@les7arts.com>:

> Thanks for the proposition Jacopo,
>
> Inline...
>
> From: <ad...@sandglass-software.com>
>> I think Example should stay in the framework, but get rid of all of  
>>  the "showroom" stuff that has been added to it. In other words,  
>> keep  it and return it to its original purpose - a very basic  
>> component for  new users to understand OFBiz.
>
> I agree notably the forms page  
> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples

Form widget examples, Ajax examples, Portal examples, JCR examples,  
etc. All of it. This was supposed to be a stripped down application  
that would not overwhelm a new user.

-Adrian

Re: Lose Weight Program for OFBiz

[Jacques Le Roux <ja...@les7arts.com>]

From: "Olivier Heintz" <ho...@nereide.biz>
>> Le 18/03/2012 13:05, Jacques Le Roux a écrit :
>> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:

>>> O) framework/documents: move the content to Wiki and then move to "Attic"

>> So get rid of the online help also?

> online help is more efficient way to have end user help and sometime existing feature boundary. In some customer project online 
> help is using to define what is operational or not, it's very convenient for business Analyst and End user.

Yes that's why I asked this question. I don't use the online help but it seems something interesting to me, not sure if/how users 
are using it...

Jacques 

Re: Lose Weight Program for OFBiz

[Olivier Heintz <ho...@nereide.biz>]

Inline

Le 18/03/2012 13:05, Jacques Le Roux a écrit :
> Thanks for the proposition Jacopo,
>
> Inline...
>
> From: <ad...@sandglass-software.com>
>> I think Example should stay in the framework, but get rid of all of  
>> the "showroom" stuff that has been added to it. In other words, keep  
>> it and return it to its original purpose - a very basic component 
>> for  new users to understand OFBiz.
+1
>
> I agree notably the forms page 
> https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
>
> The rest could be in specialpurpose, with another name?
>
>> I use datafile to connect legacy systems to OFBiz.
I've never used except 1 month ago ;-) , and it was very effective.
>>
>> I agree that specialpurpose should be slimmed down, but we should  
>> retain one or two components to demonstrate the concept of reusing  
>> artifacts to create custom applications.
+1
>
> Yes, ecomclone for instance should stay with ecommerce
>
>> -Adrian
>>
>> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:
>>
>>>
...
>>>
>>> IMPORTANT: Please consider that the list is not based on what I  
>>> think the perfect framework should be (so PLEASE do not reply  
>>> stating what your ideal framework should have), but simply on the  
>>> following considerations:
>>> * can the component be easily removed by the project? is it  
>>> independent and can live outside as a plugin?
>>> * do we need all this custom code? can't we find a simpler, lighter  
>>> and better way to implement this?
>>> * is this feature used by other code in the system?
>>> * is the feature functional? or is it largely incomplete?
>>> * is this an old component/code?
>>> * is this used by a lot of persons? (this is tricky to decide but  
>>> you can get a feeling of it by reading the mailing lists,  
>>> considering commit activity, the status of the feature etc...)
>>>
>>> DISCLAIMER: I know it will be a painful decision because each of us  
>>> reading this will have a connection with some of the code listed  
>>> below: several hours spent on it, great ideas that never came to a  
>>> finished plan; in fact I feel the same for a few of the things in  
>>> the list.... there are great ideas that didn't come to a  
>>> finalization... it doesn't mean that moving them out of the project  
>>> will kill them and this may actually help to get more visibility 
>>> and  different user group; so please when you will read it... think 
>>> to  the greater good of the community.
>>>
>>> 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"
>>>
>>> And now (drums)..... THE LIST - PART 1(but this is really a very  
>>> first pass only, PART 2 will come soon with more granular -  
>>> subcomponent - details):
>>>
>>> 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
>
> I can handle the  framework/guiapp move to pos component
>
>>> B) specialpurpose/pos: move to "Extras"
>>>
>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>>
>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>>
>>> E) specialpurpose/workflow: move to "Attic"
>>>
>>> F) specialpurpose/shark: move to "Attic"
>>>
>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>
> specialpurpose/ofbizwebsite could go to extras rather... if someone is 
> interested to continue the effort...
+1
>
>>> 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"
>>>
>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of  
>>> them to "Extras"; keep just one (or two)
only one and other to extras, in our customer project, all are using 
depending on end-user choice
>
> I would move all to extras and keep Tomahawk and Flat Grey. I'd prefer 
> to keep Tomahawk  the defautl as it is now.
>
>>> J) framework/appserver: move to "Extras"
>>>
>>> K) framework/jetty: move to "Extras" (or "Attic")
>>>
>>> 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"
>>>
>>> N) framework/jcr: move back into the Jackrabbit branch until the  
>>> work is completed and can replace the existing "content framework"
+1
>
> This should be coordinated with  
> https://issues.apache.org/jira/browse/OFBIZ-4709
>
>>> O) framework/documents: move the content to Wiki and then move to 
>>> "Attic"
>
> So get rid of the online help also?
online help is more efficient way to have end user help and sometime 
existing feature boundary. In some customer project online help is using 
to define what is operational or not, it's very convenient for business 
Analyst and End user.
>
>>> P) framework/datafile: (who is currently using it?) move to 
>>> "Extras"  or "Attic"; we could replace it with commons-csv or 
>>> similar tool
>
> I second Adrian on datafile. Though I have not used it for years, it 
> can be handy at any moment.
>
>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>
>>> Kind regards,
>>>
>>> Jacopo
>
> For the rest I agree
>
> Jacques
>

Re: Lose Weight Program for OFBiz

[Jacques Le Roux <ja...@les7arts.com>]

Thanks for the proposition Jacopo,

Inline...

From: <ad...@sandglass-software.com>
>I think Example should stay in the framework, but get rid of all of  
> the "showroom" stuff that has been added to it. In other words, keep  
> it and return it to its original purpose - a very basic component for  
> new users to understand OFBiz.

I agree notably the forms page 
https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples

The rest could be in specialpurpose, with another name?
 
> I use datafile to connect legacy systems to OFBiz.
> 
> I agree that specialpurpose should be slimmed down, but we should  
> retain one or two components to demonstrate the concept of reusing  
> artifacts to create custom applications.

Yes, ecomclone for instance should stay with ecommerce

> -Adrian
> 
> Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:
> 
>> In the last period the OFBiz project has grown a lot in shape: the  
>> implicitly accepted (or tolerated) strategy operated by the active  
>> committers was that the more features you could add to the official  
>> repository the better was: you make happy the contributors, making  
>> them feel like they are a part of something, and each committer  
>> could manage the code implemented for his/her own projects directly  
>> in the OFBiz codebase.
>>
>> We operated under the concept that, since the code if "free" and the  
>> author (committer or not) is willing to contribute it, then no one  
>> should/could complain if it is added to the repository, if it  
>> doesn't cause immediate problems to others; all in all it is an  
>> additional feature that may be used by someone else in the future or  
>> if not would simply stay there without causing any harm.
>> Following this strategy we got a lot of code like for example  
>> Webslinger, seleniumxml, debian packages, all sort of specialpurpose  
>> applications etc...
>>
>> Since there was not a central and agreed upon roadmap, no one could  
>> really state that a contribution was not a good fit for the project:  
>> each and every committer could add what, in his own personal vision,  
>> was good for the project.
>>
>> The wrong assumption is that, since the code if "free" then it  
>> doesn't harm to include it. This is completely *wrong*: the code is  
>> not *free* at all because as soon as you add it to the repository  
>> then you add a future cost to the community: you all know that in  
>> the software industry the cost to maintain a piece of code is by far  
>> greater than the cost to write it; and you *have* to maintain the  
>> code unless you want to have and distribute stale code.
>> And this is exactly what we have now:
>> * high costs to maintain the code (e.g. I recently spent a lot of  
>> hours to remove the Webslinger component)
>> * stale/unused/half baked code that causes confusion and bad  
>> impression to user evaluating the quality of our product
>>
>> The message to all the committers is: when you add code to the  
>> repository, you are asking the community to take care of its  
>> maintenance costs forever. So please, add new code only when it is  
>> really beneficial to the project and to a large audience of  
>> committers and users.
>>
>> It is like feeding a wild animal at the zoo with chips: everyone  
>> knows it is bad for its health but when you are there it is so nice  
>> when it picks the food from your own hands and you cannot resist and  
>> have to feed it.
>>
>> OFBiz is now suffering from serious weight issues: the committers  
>> community is having an hard time to maintain the huge codebase, it  
>> is difficult to keep track of all the features in the system etc...
>>
>> I think it is important to start a new phase of the project and  
>> focus our energy in cleanup and consolidation of what we have. One  
>> step in this direction is for OFBiz to lose weight.
>>
>> In order to get the ball rolling and focus on some concrete tasks I  
>> am providing here some examples of stuff that I would like to see  
>> removed from the project.
>>
>> IMPORTANT: Please consider that the list is not based on what I  
>> think the perfect framework should be (so PLEASE do not reply  
>> stating what your ideal framework should have), but simply on the  
>> following considerations:
>> * can the component be easily removed by the project? is it  
>> independent and can live outside as a plugin?
>> * do we need all this custom code? can't we find a simpler, lighter  
>> and better way to implement this?
>> * is this feature used by other code in the system?
>> * is the feature functional? or is it largely incomplete?
>> * is this an old component/code?
>> * is this used by a lot of persons? (this is tricky to decide but  
>> you can get a feeling of it by reading the mailing lists,  
>> considering commit activity, the status of the feature etc...)
>>
>> DISCLAIMER: I know it will be a painful decision because each of us  
>> reading this will have a connection with some of the code listed  
>> below: several hours spent on it, great ideas that never came to a  
>> finished plan; in fact I feel the same for a few of the things in  
>> the list.... there are great ideas that didn't come to a  
>> finalization... it doesn't mean that moving them out of the project  
>> will kill them and this may actually help to get more visibility and  
>> different user group; so please when you will read it... think to  
>> the greater good of the community.
>>
>> 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"
>>
>> And now (drums)..... THE LIST - PART 1(but this is really a very  
>> first pass only, PART 2 will come soon with more granular -  
>> subcomponent - details):
>>
>> 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

I can handle the  framework/guiapp move to pos component

>> B) specialpurpose/pos: move to "Extras"
>>
>> C) $OFBIZ_HOME/debian: move to "Attic"
>>
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>
>> E) specialpurpose/workflow: move to "Attic"
>>
>> F) specialpurpose/shark: move to "Attic"
>>
>> G) specialpurpose/ofbizwebsite: move to "Attic"

specialpurpose/ofbizwebsite could go to extras rather... if someone is interested to continue the effort...

>> 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"
>>
>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of  
>> them to "Extras"; keep just one (or two)

I would move all to extras and keep Tomahawk and Flat Grey. I'd prefer to keep Tomahawk  the defautl as it is now.

>> J) framework/appserver: move to "Extras"
>>
>> K) framework/jetty: move to "Extras" (or "Attic")
>>
>> 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"
>>
>> N) framework/jcr: move back into the Jackrabbit branch until the  
>> work is completed and can replace the existing "content framework"

This should be coordinated with  https://issues.apache.org/jira/browse/OFBIZ-4709

>> O) framework/documents: move the content to Wiki and then move to "Attic"

So get rid of the online help also?

>> P) framework/datafile: (who is currently using it?) move to "Extras"  
>> or "Attic"; we could replace it with commons-csv or similar tool

I second Adrian on datafile. Though I have not used it for years, it can be handy at any moment.

>> Q) framework/example and framework/exampleext: move to specialpurpose
>>
>> Kind regards,
>>
>> Jacopo

For the rest I agree

Jacques

Re: Lose Weight Program for OFBiz

[ad...@sandglass-software.com]

I think Example should stay in the framework, but get rid of all of  
the "showroom" stuff that has been added to it. In other words, keep  
it and return it to its original purpose - a very basic component for  
new users to understand OFBiz.

I use datafile to connect legacy systems to OFBiz.

I agree that specialpurpose should be slimmed down, but we should  
retain one or two components to demonstrate the concept of reusing  
artifacts to create custom applications.

-Adrian

Quoting Jacopo Cappellato <ja...@hotwaxmedia.com>:

> In the last period the OFBiz project has grown a lot in shape: the  
> implicitly accepted (or tolerated) strategy operated by the active  
> committers was that the more features you could add to the official  
> repository the better was: you make happy the contributors, making  
> them feel like they are a part of something, and each committer  
> could manage the code implemented for his/her own projects directly  
> in the OFBiz codebase.
>
> We operated under the concept that, since the code if "free" and the  
> author (committer or not) is willing to contribute it, then no one  
> should/could complain if it is added to the repository, if it  
> doesn't cause immediate problems to others; all in all it is an  
> additional feature that may be used by someone else in the future or  
> if not would simply stay there without causing any harm.
> Following this strategy we got a lot of code like for example  
> Webslinger, seleniumxml, debian packages, all sort of specialpurpose  
> applications etc...
>
> Since there was not a central and agreed upon roadmap, no one could  
> really state that a contribution was not a good fit for the project:  
> each and every committer could add what, in his own personal vision,  
> was good for the project.
>
> The wrong assumption is that, since the code if "free" then it  
> doesn't harm to include it. This is completely *wrong*: the code is  
> not *free* at all because as soon as you add it to the repository  
> then you add a future cost to the community: you all know that in  
> the software industry the cost to maintain a piece of code is by far  
> greater than the cost to write it; and you *have* to maintain the  
> code unless you want to have and distribute stale code.
> And this is exactly what we have now:
> * high costs to maintain the code (e.g. I recently spent a lot of  
> hours to remove the Webslinger component)
> * stale/unused/half baked code that causes confusion and bad  
> impression to user evaluating the quality of our product
>
> The message to all the committers is: when you add code to the  
> repository, you are asking the community to take care of its  
> maintenance costs forever. So please, add new code only when it is  
> really beneficial to the project and to a large audience of  
> committers and users.
>
> It is like feeding a wild animal at the zoo with chips: everyone  
> knows it is bad for its health but when you are there it is so nice  
> when it picks the food from your own hands and you cannot resist and  
> have to feed it.
>
> OFBiz is now suffering from serious weight issues: the committers  
> community is having an hard time to maintain the huge codebase, it  
> is difficult to keep track of all the features in the system etc...
>
> I think it is important to start a new phase of the project and  
> focus our energy in cleanup and consolidation of what we have. One  
> step in this direction is for OFBiz to lose weight.
>
> In order to get the ball rolling and focus on some concrete tasks I  
> am providing here some examples of stuff that I would like to see  
> removed from the project.
>
> IMPORTANT: Please consider that the list is not based on what I  
> think the perfect framework should be (so PLEASE do not reply  
> stating what your ideal framework should have), but simply on the  
> following considerations:
> * can the component be easily removed by the project? is it  
> independent and can live outside as a plugin?
> * do we need all this custom code? can't we find a simpler, lighter  
> and better way to implement this?
> * is this feature used by other code in the system?
> * is the feature functional? or is it largely incomplete?
> * is this an old component/code?
> * is this used by a lot of persons? (this is tricky to decide but  
> you can get a feeling of it by reading the mailing lists,  
> considering commit activity, the status of the feature etc...)
>
> DISCLAIMER: I know it will be a painful decision because each of us  
> reading this will have a connection with some of the code listed  
> below: several hours spent on it, great ideas that never came to a  
> finished plan; in fact I feel the same for a few of the things in  
> the list.... there are great ideas that didn't come to a  
> finalization... it doesn't mean that moving them out of the project  
> will kill them and this may actually help to get more visibility and  
> different user group; so please when you will read it... think to  
> the greater good of the community.
>
> 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"
>
> And now (drums)..... THE LIST - PART 1(but this is really a very  
> first pass only, PART 2 will come soon with more granular -  
> subcomponent - details):
>
> 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"
>
> C) $OFBIZ_HOME/debian: move to "Attic"
>
> D) the seleniumxml code in framework/testtools: move to "Attic"
>
> E) specialpurpose/workflow: move to "Attic"
>
> F) specialpurpose/shark: move to "Attic"
>
> G) specialpurpose/ofbizwebsite: move to "Attic"
>
> 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"
>
> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of  
> them to "Extras"; keep just one (or two)
>
> J) framework/appserver: move to "Extras"
>
> K) framework/jetty: move to "Extras" (or "Attic")
>
> 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"
>
> N) framework/jcr: move back into the Jackrabbit branch until the  
> work is completed and can replace the existing "content framework"
>
> O) framework/documents: move the content to Wiki and then move to "Attic"
>
> P) framework/datafile: (who is currently using it?) move to "Extras"  
> or "Attic"; we could replace it with commons-csv or similar tool
>
> Q) framework/example and framework/exampleext: move to specialpurpose
>
> Kind regards,
>
> Jacopo
>
>