Lose Weight Program for OFBiz

[Jacopo Cappellato-4]

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

[Scott Gray-2]

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

[Jacques Le Roux]

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

Jacques

[hans_bakker]

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

[hans_bakker]

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

[Jacopo Cappellato-4]

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

[Jacques Le Roux]

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" <[hidden email]>
>A point I'd like to emphasize: before moving things out we should check all related pending Jiras
>
> Jacques

[Olivier.heintz]

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

[Pierre Smits]

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 <[hidden email]> 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 <jacopo.cappellato@**hotwaxmedia.com<[hidden email]>
> >:
>
>  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
>>
>>
>>
>
>
>

[Pierre Smits]

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

[Jacopo Cappellato-4]

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
>

[hans_bakker]

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

[Jacopo Cappellato-4]

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

[Jacopo Cappellato-4]

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

[Jacopo Cappellato-4]

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

[Jacopo Cappellato-4]

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

[Jacopo Cappellato-4]

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

[Jacopo Cappellato-4]

> 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

[Jacopo Cappellato-4]

> 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

[Jacopo Cappellato-4]

> 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