Marketing OFBiz and the OFBiz non-object approach (was Re: Wicket in OFBiz)

[BJ Freeman]

what I pick up is you are saying ofbiz is no longer valid and now Moqui is.
How I evaluate that is what is to say that Moqui also will not be valid
at some point so why invest in Moqui.


=========================

BJ Freeman
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


David E Jones sent the following on 1/25/2011 1:53 PM:

>
> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>
>> On 1/25/11 2:06 AM, David E Jones wrote:
>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>
> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>
> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>
> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>
> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>
> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>
> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>
> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>
> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>
> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>
> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>
> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>
> I should get back to work... there's a short list anyway...
>
> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>
> -David
>
>
>

[David E. Jones-2]

This doesn't make sense... what does "valid" mean in what you wrote?

Trying to understand more generally: are you arguing against progress in general, or just in the case of OFBiz? Do you still drive the first car you ever bought, or a more recently manufactured one of the same design? Wait... maybe that's a bad question because maybe you do... a better question is do you think that most people do or that car companies should continue producing cars designed in the '50s or '60s or '70s?

On a related note: How would you feel about a framework designer, or politician, or anyone in any field who stuck by their positions from a decade ago just to stand by them, even their are clearly better ideas around and problems with the old ones?

To answer another possible question: yes, in another 10 years I may abandon Moqui and the data model and other projects based on it and do yet another framework. Or, more hopefully, because the Moqui Framework is separate from the rest of those projects we can do new versions of Moqui that are forked from the previous version (as many projects do, Tomcat is a great example of this) and let the other projects update whenever they feel like it, and continue to use older versions as long as it makes sense for them.

-David


On Jan 25, 2011, at 2:09 PM, BJ Freeman wrote:

> what I pick up is you are saying ofbiz is no longer valid and now Moqui is.
> How I evaluate that is what is to say that Moqui also will not be valid at some point so why invest in Moqui.
>
>
> =========================
>
> BJ Freeman
> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat  Y! messenger: bjfr33man
>
>
> David E Jones sent the following on 1/25/2011 1:53 PM:
>>
>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>
>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>>
>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>
>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>
>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>
>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>
>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>
>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>
>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>
>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>
>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>
>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>
>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>
>> I should get back to work... there's a short list anyway...
>>
>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>
>> -David
>>
>>
>>
>

[Ruth Hoffman-2]

David:
Thanks for elaborating. IMHO, nothing you have outlined here is a show
stopper. What a shame that you can't see what others (many others...I'm
finding more each day) can clearly see: OFBiz is the best thing out
there. It may not be perfect in your eyes, but another framework isn't
the answer. IMHO, understanding how to work around any objections, being
honest and open about any limitations (if they really do exist) and
remaining open to new ways of thinking about OFBiz is the only way forward.

Regards,
Ruth

On 1/25/11 4:53 PM, David E Jones wrote:

> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>
>> On 1/25/11 2:06 AM, David E Jones wrote:
>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>
> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>
> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>
> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>
> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>
> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>
> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>
> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>
> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>
> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>
> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>
> I should get back to work... there's a short list anyway...
>
> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>
> -David
>
>
>

[David E. Jones-2]

I agree, though I am biased, Apache OFBiz IS the best thing out there. However, I don't think OFBiz is the best thing that COULD be out there.

That said, I don't think that everyone should take the approach I am taking. If everyone did, there would be too much competition for me. On the other hand, if I personally did not take this approach... OFBiz would not exist.

-David


On Jan 25, 2011, at 2:19 PM, Ruth Hoffman wrote:

> David:
> Thanks for elaborating. IMHO, nothing you have outlined here is a show stopper. What a shame that you can't see what others (many others...I'm finding more each day) can clearly see: OFBiz is the best thing out there. It may not be perfect in your eyes, but another framework isn't the answer. IMHO, understanding how to work around any objections, being honest and open about any limitations (if they really do exist) and remaining open to new ways of thinking about OFBiz is the only way forward.
>
> Regards,
> Ruth
>
> On 1/25/11 4:53 PM, David E Jones wrote:
>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>
>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>
>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>
>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>
>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>
>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>
>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>
>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>
>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>
>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>
>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>
>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>
>> I should get back to work... there's a short list anyway...
>>
>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>
>> -David
>>
>>
>>
>

[David E. Jones-2]

This thread is pushing buttons that haven't been pushed in a while... but they have certainly been pushed before (in the mailing lists, if you like history). Unfortunately this will bring out more of my jaded attitude towards various things... ;)

Right now Apache OFBiz is fairly mature (no huge gaping holes needing to be filled as was the case for the first 5-6 years of the project), and being part of the ASF is currently operated in a legitimate and respectable and proper... bureaucracy.

Being led in a bureaucratic way it is beyond the realm of influence by doers. At this point the only form of leadership that will work is by those who have survived the world of business by getting other people to do what they want because they could not do it themselves. The project now needs someone who thrives on dealing with complaints because that is the primary form of currency in bureaucracies (well, aside from actual currency, but being an open source project with no armed tax and fee policy enforcers there isn't a lot of that around).

Now assuming such a person were in place and accepted by the PMC and committers and a proper leader... what is the direction the project should go? What should it commit to and on what timeline? Who should decide on the direction and the timeline?

In short:

1. Who decides on the objective(s)?
2. How do you get other volunteers to play along, and commit to a timeline?
3. What objectives would we pursue in OFBiz at this point in its life?

-David


On Jan 25, 2011, at 3:43 AM, Pierre Smits wrote:

> IMO, marketing has to do with managing (and steering) expectations. For the
> generally accepted explanation, see http://en.wikipedia.org/wiki/Marketing
>
> Marketing OFBiz to either the development community or others will always be
> an uphill battle, when you don't have a plan. And I think that is the
> underlying issue. More on this later...
>
> Since 2006 I have followed the mailing lists (all of them of OFBiz),
> reacting on entries there, occasionally created awareness for issues (by
> registering them in JIRA) and providing patches and improvements. Like all
> of us I have only limited time available for OFBiz (the project), as it is
> not the source of income.
>
> And I see a lot of involved and enthousiast persons doing the same as I do.
> When feeling a pain with OFBiz (the product) I try to take the pain away.
> And if there is time to spare I bring back to OFBiz (the community). Without
> any (perceived) commitment or responsibility. The general approach seems to
> be: 'Yes, it will happen when it happens'. I even see committers taking this
> further: plemping code straight into the trunk (or removing from) without
> prior consensus of the community, and then thumping their chests and
> hailing (marketing) their prowess.
>
> Is this how it's supposed to be in this project/communtiy?
>
> Back to the underlying issue.
> I have come to believe that OFBiz is a project without a plan. Yes, we have
> the marketing documents (about the product, project and the community
> members), but only about what is/was and what has happened. But we have
> nothing to say about what is going to be or happen. Maybe on an individual
> (member) level to an individual customer (group). But not as WE the
> community/project. And this should change if we want to able give more
> praise, business, etc to our members. How can we get new followers and old
> interested when we can't even say:
>
> Look guys. This is what we are working on and it *will* be available at such
> and such moment. Please come back here to check on our progress and other
> plans.
>
> Journalists and other followers are looking for this. And this is what we
> have to do and do it regularly.
> But we can't do this when we don't have a clue what is going to happen with
> the product and project. We can only comment vaguely about what is happening
> in JIRA and in mailing lists. But not about the way forward. And not to loud
> as it might bite us in the behind.
>
> Maybe it is time for a change. But another change than implementing yet
> another wheel (or bathtub) on the car. Or replacing one working wheel with
> another.
>
> Regards,
>
> Pierre Smits

[rajsaini]

David,

I agree with you that  a complete overhaul or rather a new design of the
OFBiz framework is needed taking into new ideas and new technologies
into consideration. Moreover, as any software grows and matures it
becomes extremely difficult to make changes due to the backward
compatibility and this phenomena is not really new to OFBiz. You will
see this around happening to any other big project.

Recent example is Eclipse 4.0. Eclipse community wanted to incorporate
new features based on service oriented architecture and they could not
do it with Eclipse 3.0 due to dreaded backward compatibility issues.
What did they do? Started a brand new project under Eclipse foundation
and that is without killing the 3.0. There are many more example around.
Linux and FSF world is full of -ng and that includes small and big projects.

So we need here in OFBiz is a new generation OFBiz that is OFBizNG. A
brand new OFBiz which builds on top of current without worrying about
the backward compatibility issues.

So my question is why cant Mouqi be a OFBizNG? As it is going to be a
sub project of the OFBiz, it can have different commitors, different set
of commit rules, and you can take a leadeship roles as you are the most
experienced person.

Thanks,

Raj

On Wednesday 26 January 2011 03:23 AM, David E Jones wrote:

> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>
>> On 1/25/11 2:06 AM, David E Jones wrote:
>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>
> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>
> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>
> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>
> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>
> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>
> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>
> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>
> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>
> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>
> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>
> I should get back to work... there's a short list anyway...
>
> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>
> -David
>
>
>

[Adrian Crum-3]

Many of the things listed here have been discussed, and as far as I can
tell, there is no objection to making those changes - we just need the
manpower to do it.

Item #7 has been discussed and there hasn't been any argument against
that change - except that it touches on the backwards-compatibility
issue. And I'm going to use this opportunity to address that issue.

Some of the changes mentioned here wouldn't affect any of my projects -
because I don't attempt to patch or modify the framework - I only build
applications on it. Other changes mentioned here would make application
development easier.

The other day Ryan Foster described the backwards-compatibility talk as
a mantra. I view it as more of a straw man. Five days ago I posed this
question to the user mailing list:

"Would you, as an end user of OFBiz, knowing that the OFBiz project
could be improved greatly - but at the cost of some backward
incompatibility - accept the changes? If yes, how often would
backwards-incompatible changes be acceptable?"

It is interesting to note that in a list of over 400 subscribers, no one
has replied.

The most vocal proponents of backwards-compatibility (in the framework)
are a few players who have modified the framework locally. As a
community, do we really want to allow those few members to stifle
innovation?

Some users claimed the updated Flat Grey visual theme wasn't "backwards
compatible."  What does that even mean? Some colors and background
images were changed - how is that backwards incompatible?

To be fair, I have been an advocate for backwards-compatibility. But
that has been for things that break application functionality.

At the least, there needs to be a compromise. At best, there needs to be
acceptance of the possibility of future versions that are not backwards
compatible with previous versions. That concept is not new or
revolutionary - it goes on in every software project, both open source
and commercial.

David has some great ideas, but he feels compelled to start over from
scratch to implement them. From my perspective, that's a tragedy. One of
the project's founders feels the need to start another project as a last
resort to make the project he originally started better. Does that make
sense?

I don't want to use Moqui. It's an unfinished framework controlled by
one person and it has no applications built around it. Bottom line -
it's not an option. What I want is  Moqui's innovations in OFBiz.

I believe it's time we have a serious discussion about this. Users have
commented that there is no plan for OFBiz - what is planned for its
future? They're right. Maybe we should come up with some plans, or some
kind of path to the future.

I propose we put all the cards on the table. Where do we go from here?
Continue on our present path and have competing projects that improve on
OFBiz technology?  Try to keep innovation in the project at the expense
of some backwards incompatibility? Maintain backwards compatibility by
forking the project to something new? Or have milestone versions that
are clearly marketed as backwards incompatible with previous milestone
versions?

Lately, it seems many of the big players in the OFBiz developer
community have been absent on the mailing list. I understand that this
is a volunteer community, but at the same time, we all have a say, and
that "say" depends on us saying *something.*

So, please say something.

-Adrian


On 1/25/2011 1:53 PM, David E Jones wrote:

> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>
>> On 1/25/11 2:06 AM, David E Jones wrote:
>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>
> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>
> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>
> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>
> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>
> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>
> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>
> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>
> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>
> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>
> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>
> I should get back to work... there's a short list anyway...
>
> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>
> -David
>
>

[Jacopo Cappellato-4]

There are so many interesting topics in this thread and for now I will comment on few of them (in spare order):

1) backward compatibility: we already have to stable release branches (and we will probably create another one soon) and users can use them and be sure that future releases *within* the branch will be backward compatible; I mean that 10.04.01, 10.04.02, 10.04.03 etc... will be backward compatible with 10.04 but not with the 09.04 series; future release branches can (and in my opinion *should*) be free to break backward compatibility; of course the community, or even better, commercial vendors could create migration scripts for, let's say, users of 09.04 series to help them migrate t the 10.04 series; but this is not something that the community *has* to do; it is important that the history behind OFBiz is treated as a valuable asset of the project and not as an burden; to summarize: backward compatibility should be considered only for the commits of a given release branch and should not be a limitation for development in the trunk

2) refactoring the OFBiz framework: I would be very happy to discuss and implement a newer version of the framework; I think that we should get a much lighter framework working into the following directions:
2.0) before any action can be taken we should finally find an agreement for a definition of the framework; what is it? how should be used? IMO something like "a framework for building ERP applications (characterized by extensive relational data model and several business processes that manage the data) with browser friendly ui" is a good start
2.a) removing old or not used (by the official applications) artifacts and tools; ideally we should have one implementation for each tool required; alternate implementation should go away;
2.b) removing (or at least revisiting the way they have been integrated) big external chunks of other projects; they could be moved to a separate "extra" folder (possibly together with part of the 2.a stuff), not built by default and not included in our official releases (instead they could be released separately)
2.c) enhance/simplify the tools we want to keep based on the features/best practices that proved their validity in the history of the project (in an evolutionary context)
2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the official applications to reflect the changes in the framework (more about this in point 2.e)
2.e) application and special purpose components: at some point we may realize that, in order to reflect the changes in the framework, it would be easier to rewrite/refactor (part of) them instead of updating them; at that point we may create a freeze/branch of OFBiz and remove the applications from the trunk; then migrate to the trunk the parts that we want to keep in the new generation OFBiz; we could even end up with a completely different structure like: one component for the generic ERP application (combining together part of several existing applications like party, product, order etc... that are already interdependent) plus a series of vertical components (still rather generic); or one generic component containing generic business logic (services) and data models for a generic ERP and then several different components with different ui for different industries (like one for retailers, one for manufacturers etc...)

3) issues with bureaucracy: it is definitely true that being part of the ASF oblige us to follow and respect some rules; this is sometime a pain, especially when the rules conflicts with the greater good of the project (see for example the issues with the ASF resources that we were forced to adopt); however I don't think that the issues we see in the community and in OFBiz are caused by this or by the PMC; I think that the main issues are caused by the attitude of people working in the community, by conflicting goals and expectations, by the lack of a shared goal (or by the hidden presence of several conflicting personal goals), by the huge size of OFBiz and by its long history; these are indeed issues that we have to tackle and try to resolve together with a positive attitude but they could happen in every other big group of people working with different goals on the same shared resource; we should not blame the ASF or the PMC for this

Kind regards,

Jacopo

On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:

> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we just need the manpower to do it.
>
> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>
> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the framework - I only build applications on it. Other changes mentioned here would make application development easier.
>
> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago I posed this question to the user mailing list:
>
> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>
> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>
> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework locally. As a community, do we really want to allow those few members to stifle innovation?
>
> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and background images were changed - how is that backwards incompatible?
>
> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application functionality.
>
> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software project, both open source and commercial.
>
> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally started better. Does that make sense?
>
> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it. Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>
> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>
> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility? Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as backwards incompatible with previous milestone versions?
>
> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>
> So, please say something.
>
> -Adrian
>
>
> On 1/25/2011 1:53 PM, David E Jones wrote:
>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>
>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>
>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>
>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>
>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>
>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>
>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>
>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>
>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>
>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>
>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>
>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>
>> I should get back to work... there's a short list anyway...
>>
>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>
>> -David
>>
>>
>

[Jacques Le Roux]

From: "Jacopo Cappellato" <[hidden email]>

> There are so many interesting topics in this thread and for now I will comment on few of them (in spare order):
>
> 1) backward compatibility: we already have to stable release branches (and we will probably create another one soon) and users can
> use them and be sure that future releases *within* the branch will be backward compatible; I mean that 10.04.01, 10.04.02,
> 10.04.03 etc... will be backward compatible with 10.04 but not with the 09.04 series; future release branches can (and in my
> opinion *should*) be free to break backward compatibility; of course the community, or even better, commercial vendors could
> create migration scripts for, let's say, users of 09.04 series to help them migrate t the 10.04 series; but this is not something
> that the community *has* to do; it is important that the history behind OFBiz is treated as a valuable asset of the project and
> not as an burden; to summarize: backward compatibility should be considered only for the commits of a given release branch and
> should not be a limitation for development in the trunk

The migration scripts idea (especially if commercial vendors are involved) is a very good idea. This could foster an ecosystem
around OFBiz with differenret versions still compatible. Even without it, I think going the Tomcat way (as David outlined, or HTTPD
also) would relieve us of the burden of updating endlessly versions. It's already the case, the verion 4.0 is ignored by us, we
don't update it
anymore. I have even created a specific Jira for valuable R4.0 patches https://issues.apache.org/jira/browse/OFBIZ-3268

> 2) refactoring the OFBiz framework: I would be very happy to discuss and implement a newer version of the framework; I think that
> we should get a much lighter framework working into the following directions:
> 2.0) before any action can be taken we should finally find an agreement for a definition of the framework; what is it? how should
> be used? IMO something like "a framework for building ERP applications (characterized by extensive relational data model and
> several business processes that manage the data) with browser friendly ui" is a good start
> 2.a) removing old or not used (by the official applications) artifacts and tools; ideally we should have one implementation for
> each tool required; alternate implementation should go away;
> 2.b) removing (or at least revisiting the way they have been integrated) big external chunks of other projects; they could be
> moved to a separate "extra" folder (possibly together with part of the 2.a stuff), not built by default and not included in our
> official releases (instead they could be released separately)
> 2.c) enhance/simplify the tools we want to keep based on the features/best practices that proved their validity in the history of
> the project (in an evolutionary context)
> 2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the official applications to reflect the changes in the framework
> (more about this in point 2.e)
> 2.e) application and special purpose components: at some point we may realize that, in order to reflect the changes in the
> framework, it would be easier to rewrite/refactor (part of) them instead of updating them; at that point we may create a
> freeze/branch of OFBiz and remove the applications from the trunk; then migrate to the trunk the parts that we want to keep in the
> new generation OFBiz; we could even end up with a completely different structure like: one component for the generic ERP
> application (combining together part of several existing applications like party, product, order etc... that are already
> interdependent) plus a series of vertical components (still rather generic); or one generic component containing generic business
> logic (services) and data models for a generic ERP and then several different components with different ui for different
> industries (like one for retailers, one for manufacturers etc...)

Good ideas, but I'm afraid we still lack human ressources for this to happen, at least at short/mid term. Also one David point (even
if not in the 7 list) is he wants a better control of code access permissions...

> 3) issues with bureaucracy: it is definitely true that being part of the ASF oblige us to follow and respect some rules; this is
> sometime a pain, especially when the rules conflicts with the greater good of the project (see for example the issues with the ASF
> resources that we were forced to adopt); however I don't think that the issues we see in the community and in OFBiz are caused by
> this or by the PMC; I think that the main issues are caused by the attitude of people working in the community, by conflicting
> goals and expectations, by the lack of a shared goal (or by the hidden presence of several conflicting personal goals), by the
> huge size of OFBiz and by its long history; these are indeed issues that we have to tackle and try to resolve together with a
> positive attitude but they could happen in every other big group of people working with different goals on the same shared
> resource; we should not blame the ASF or the PMC for this

I can't agree more. Note though that infra team has been kind enough to double our memory ressources recently. It was a bit of work
to convince them, but they are open and happy to help, not a blind bureaucracy! Now, since almost a month, we have *any issues* with
the demo instances, and I'm very happy with that.

Most of the time we have to be patient when a conflict occurs between committers. It's often limited human ressources and pressure
of time which raises those conflicts, Zen attitude helps then (I speak for myself ;o). But we should never forget those issues when
they arise and discuss as much as needed. Else one day they come back with more force and sometimes it's too late to handle them.

My 2cts

Jacques

> Kind regards,
>
> Jacopo
>
> On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
>
>> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we
>> just need the manpower to do it.
>>
>> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the
>> backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>>
>> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the
>> framework - I only build applications on it. Other changes mentioned here would make application development easier.
>>
>> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago
>> I posed this question to the user mailing list:
>>
>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward
>> incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>>
>> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>>
>> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework
>> locally. As a community, do we really want to allow those few members to stifle innovation?
>>
>> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and
>> background images were changed - how is that backwards incompatible?
>>
>> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application
>> functionality.
>>
>> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that
>> are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software
>> project, both open source and commercial.
>>
>> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a
>> tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally
>> started better. Does that make sense?
>>
>> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it.
>> Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>>
>> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is
>> planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>>
>> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects
>> that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility?
>> Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as
>> backwards incompatible with previous milestone versions?
>>
>> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that
>> this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>>
>> So, please say something.
>>
>> -Adrian
>>
>>
>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>
>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in
>>>>> many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework).
>>>>> Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting
>>>>> the approach.
>>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not
>>>> try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you
>>>> have an specific examples?
>>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and
>>> ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a
>>> few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>>
>>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about
>>> the differences between the Moqui and OFBiz frameworks:
>>>
>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>
>>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while
>>> I'm developing:
>>>
>>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many
>>> differences
>>>
>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus
>>> the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead
>>> of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set
>>> action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when
>>> squeezed into XML attributes)
>>>
>>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views;
>>> *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the
>>> application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when
>>> doing request-redirect you have to specify the parameters to use in a larger number of places
>>>
>>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the
>>> service definition (especially for smaller services), and encourage fewer services per file
>>>
>>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used
>>> are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this
>>> slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>>
>>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in
>>> other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more
>>> flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in
>>> the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of
>>> doing it); in other words, the tools don't share a context
>>>
>>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in
>>> quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because
>>> the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal
>>> implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it
>>> makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be
>>> backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and
>>> differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in
>>> OFBiz too)
>>>
>>> I should get back to work... there's a short list anyway...
>>>
>>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and
>>> then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not
>>> including everything that everyone else has written outside the project that they may want to update. And, ALL of that would
>>> have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others
>>> are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would
>>> basically be a fork anyway...
>>>
>>> -David
>>>
>>>
>>
>
>

[Pierre Smits]

If we have the consensus, a documented approach and the structure in place
the participants will follow. Some of current community will step out and
new enthousiast will get on board.

What do you mean with 'better control of code access permissions'?

Anyway, I am, and always have been, willing to participate and support
change for the better.

Regards,

Pierre

2011/1/26 Jacques Le Roux <[hidden email]>

> From: "Jacopo Cappellato" <[hidden email]>
>
>  There are so many interesting topics in this thread and for now I will
>> comment on few of them (in spare order):
>>
>> 1) backward compatibility: we already have to stable release branches (and
>> we will probably create another one soon) and users can
>> use them and be sure that future releases *within* the branch will be
>> backward compatible; I mean that 10.04.01, 10.04.02,
>> 10.04.03 etc... will be backward compatible with 10.04 but not with the
>> 09.04 series; future release branches can (and in my
>> opinion *should*) be free to break backward compatibility; of course the
>> community, or even better, commercial vendors could
>> create migration scripts for, let's say, users of 09.04 series to help
>> them migrate t the 10.04 series; but this is not something
>> that the community *has* to do; it is important that the history behind
>> OFBiz is treated as a valuable asset of the project and
>> not as an burden; to summarize: backward compatibility should be
>> considered only for the commits of a given release branch and
>> should not be a limitation for development in the trunk
>>
>
> The migration scripts idea (especially if commercial vendors are involved)
> is a very good idea. This could foster an ecosystem
> around OFBiz with differenret versions still compatible. Even without it, I
> think going the Tomcat way (as David outlined, or HTTPD
> also) would relieve us of the burden of updating endlessly versions. It's
> already the case, the verion 4.0 is ignored by us, we
> don't update it
> anymore. I have even created a specific Jira for valuable R4.0 patches
> https://issues.apache.org/jira/browse/OFBIZ-3268
>
>
>  2) refactoring the OFBiz framework: I would be very happy to discuss and
>> implement a newer version of the framework; I think that
>> we should get a much lighter framework working into the following
>> directions:
>> 2.0) before any action can be taken we should finally find an agreement
>> for a definition of the framework; what is it? how should
>> be used? IMO something like "a framework for building ERP applications
>> (characterized by extensive relational data model and
>> several business processes that manage the data) with browser friendly ui"
>> is a good start
>> 2.a) removing old or not used (by the official applications) artifacts and
>> tools; ideally we should have one implementation for
>> each tool required; alternate implementation should go away;
>> 2.b) removing (or at least revisiting the way they have been integrated)
>> big external chunks of other projects; they could be
>> moved to a separate "extra" folder (possibly together with part of the 2.a
>> stuff), not built by default and not included in our
>> official releases (instead they could be released separately)
>> 2.c) enhance/simplify the tools we want to keep based on the features/best
>> practices that proved their validity in the history of
>> the project (in an evolutionary context)
>> 2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the
>> official applications to reflect the changes in the framework
>> (more about this in point 2.e)
>> 2.e) application and special purpose components: at some point we may
>> realize that, in order to reflect the changes in the
>> framework, it would be easier to rewrite/refactor (part of) them instead
>> of updating them; at that point we may create a
>> freeze/branch of OFBiz and remove the applications from the trunk; then
>> migrate to the trunk the parts that we want to keep in the
>> new generation OFBiz; we could even end up with a completely different
>> structure like: one component for the generic ERP
>> application (combining together part of several existing applications like
>> party, product, order etc... that are already
>> interdependent) plus a series of vertical components (still rather
>> generic); or one generic component containing generic business
>> logic (services) and data models for a generic ERP and then several
>> different components with different ui for different
>> industries (like one for retailers, one for manufacturers etc...)
>>
>
> Good ideas, but I'm afraid we still lack human ressources for this to
> happen, at least at short/mid term. Also one David point (even
> if not in the 7 list) is he wants a better control of code access
> permissions...
>
>
>  3) issues with bureaucracy: it is definitely true that being part of the
>> ASF oblige us to follow and respect some rules; this is
>> sometime a pain, especially when the rules conflicts with the greater good
>> of the project (see for example the issues with the ASF
>> resources that we were forced to adopt); however I don't think that the
>> issues we see in the community and in OFBiz are caused by
>> this or by the PMC; I think that the main issues are caused by the
>> attitude of people working in the community, by conflicting
>> goals and expectations, by the lack of a shared goal (or by the hidden
>> presence of several conflicting personal goals), by the
>> huge size of OFBiz and by its long history; these are indeed issues that
>> we have to tackle and try to resolve together with a
>> positive attitude but they could happen in every other big group of people
>> working with different goals on the same shared
>> resource; we should not blame the ASF or the PMC for this
>>
>
> I can't agree more. Note though that infra team has been kind enough to
> double our memory ressources recently. It was a bit of work
> to convince them, but they are open and happy to help, not a blind
> bureaucracy! Now, since almost a month, we have *any issues* with
> the demo instances, and I'm very happy with that.
>
> Most of the time we have to be patient when a conflict occurs between
> committers. It's often limited human ressources and pressure
> of time which raises those conflicts, Zen attitude helps then (I speak for
> myself ;o). But we should never forget those issues when
> they arise and discuss as much as needed. Else one day they come back with
> more force and sometimes it's too late to handle them.
>
> My 2cts
>
> Jacques
>
>
>  Kind regards,
>>
>> Jacopo
>>
>> On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
>>
>>  Many of the things listed here have been discussed, and as far as I can
>>> tell, there is no objection to making those changes - we
>>> just need the manpower to do it.
>>>
>>> Item #7 has been discussed and there hasn't been any argument against
>>> that change - except that it touches on the
>>> backwards-compatibility issue. And I'm going to use this opportunity to
>>> address that issue.
>>>
>>> Some of the changes mentioned here wouldn't affect any of my projects -
>>> because I don't attempt to patch or modify the
>>> framework - I only build applications on it. Other changes mentioned here
>>> would make application development easier.
>>>
>>> The other day Ryan Foster described the backwards-compatibility talk as a
>>> mantra. I view it as more of a straw man. Five days ago
>>> I posed this question to the user mailing list:
>>>
>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could
>>> be improved greatly - but at the cost of some backward
>>> incompatibility - accept the changes? If yes, how often would
>>> backwards-incompatible changes be acceptable?"
>>>
>>> It is interesting to note that in a list of over 400 subscribers, no one
>>> has replied.
>>>
>>> The most vocal proponents of backwards-compatibility (in the framework)
>>> are a few players who have modified the framework
>>> locally. As a community, do we really want to allow those few members to
>>> stifle innovation?
>>>
>>> Some users claimed the updated Flat Grey visual theme wasn't "backwards
>>> compatible."  What does that even mean? Some colors and
>>> background images were changed - how is that backwards incompatible?
>>>
>>> To be fair, I have been an advocate for backwards-compatibility. But that
>>> has been for things that break application
>>> functionality.
>>>
>>> At the least, there needs to be a compromise. At best, there needs to be
>>> acceptance of the possibility of future versions that
>>> are not backwards compatible with previous versions. That concept is not
>>> new or revolutionary - it goes on in every software
>>> project, both open source and commercial.
>>>
>>> David has some great ideas, but he feels compelled to start over from
>>> scratch to implement them. From my perspective, that's a
>>> tragedy. One of the project's founders feels the need to start another
>>> project as a last resort to make the project he originally
>>> started better. Does that make sense?
>>>
>>> I don't want to use Moqui. It's an unfinished framework controlled by one
>>> person and it has no applications built around it.
>>> Bottom line - it's not an option. What I want is  Moqui's innovations in
>>> OFBiz.
>>>
>>> I believe it's time we have a serious discussion about this. Users have
>>> commented that there is no plan for OFBiz - what is
>>> planned for its future? They're right. Maybe we should come up with some
>>> plans, or some kind of path to the future.
>>>
>>> I propose we put all the cards on the table. Where do we go from here?
>>> Continue on our present path and have competing projects
>>> that improve on OFBiz technology?  Try to keep innovation in the project
>>> at the expense of some backwards incompatibility?
>>> Maintain backwards compatibility by forking the project to something new?
>>> Or have milestone versions that are clearly marketed as
>>> backwards incompatible with previous milestone versions?
>>>
>>> Lately, it seems many of the big players in the OFBiz developer community
>>> have been absent on the mailing list. I understand that
>>> this is a volunteer community, but at the same time, we all have a say,
>>> and that "say" depends on us saying *something.*
>>>
>>> So, please say something.
>>>
>>> -Adrian
>>>
>>>
>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>
>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>
>>>>  On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>
>>>>>> All of that said, now that Moqui is starting to take shape I find the
>>>>>> OFBiz Framework to be cumbersome and inconsistent in
>>>>>> many ways (things that are hard to fix, but that are not surprising
>>>>>> given the pioneering history of the OFBiz Framework).
>>>>>> Those funny quirky things are likely a turn-off to prospective
>>>>>> developers and I'm hoping to remove that impediment to adopting
>>>>>> the approach.
>>>>>>
>>>>> David - you keep saying this..Please provide some examples of
>>>>> "cumbersome and inconsistent" within the framework. And why not
>>>>> try and fix these? Instead of reinventing the wheel. What "funny
>>>>> quirky" things have turned of prospective developers? Do you
>>>>> have an specific examples?
>>>>>
>>>> Yes, I have mentioned these many times especially in the last 2-3 years.
>>>> Some of them I have tried to fix in OFBiz itself and
>>>> ran into rather large problems. These are not easy changes to make in a
>>>> large and mature project like OFBiz, and after trying a
>>>> few times I decided that a new framework was the only way forward
>>>> (another thing I've written before and made very clear).
>>>>
>>>> These are the things that led to many aspects of the design of Moqui,
>>>> and the best summary of them is the document I wrote about
>>>> the differences between the Moqui and OFBiz frameworks:
>>>>
>>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>
>>>> To sum up here are some of the major inconsistencies and annoyances in
>>>> the current OFBiz framework that bug me frequently while
>>>> I'm developing:
>>>>
>>>> 1. XML actions are different in each widget and in the simple-methods;
>>>> they share some underlying code but there are so many
>>>> differences
>>>>
>>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL,
>>>> and Groovy and keeping track of which is a pain, plus
>>>> the Groovy syntax and capabilities are SO much better than the others so
>>>> I find myself almost always using ${groovy:...} instead
>>>> of the default, and in annoying places like the form.field.@use-whenattribute since it is always BeanShell I just use a set
>>>> action to prepare a boolean and then check it in the use-when (BeanShell
>>>> is HORRIBLE compared to groovy, especially when
>>>> squeezed into XML attributes)
>>>>
>>>> 3. the controller.xml file gets HUGE for larger applications, and if
>>>> split it becomes harder to find requests and views;
>>>> *Screen.xml files also tend to get HUGE with large numbers of screens in
>>>> them; both are not organized in the same way as the
>>>> application, also generally making things harder to find; views/screens
>>>> and requests don't define incoming parameters so when
>>>> doing request-redirect you have to specify the parameters to use in a
>>>> larger number of places
>>>>
>>>> 4. another on the topic of why so many files: service groups and
>>>> simple-methods are just XML, why not include them inline in the
>>>> service definition (especially for smaller services), and encourage
>>>> fewer services per file
>>>>
>>>> 5. loading of artifacts is not very lazy, meaning lots of unused
>>>> screens, forms, services, entities and so on that are not used
>>>> are loaded anyway; also many artifacts are difficult to reload by cache
>>>> clearing and so that has limited support in OFBiz; this
>>>> slows things down reloading lots of stuff in development, and results in
>>>> more resources used than needed in production
>>>>
>>>> 6. the deployment model of OFBiz is limited and the use of static fields
>>>> for initialization makes it difficult to deploy in
>>>> other ways; there are few init/destroy methods and object instances that
>>>> would make more deployment models easier and more
>>>> flexible; also because of this it is difficult to get data from other
>>>> parts of the framework (for example the audit log stuff in
>>>> the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId
>>>> and visitId down since there is no other good way of
>>>> doing it); in other words, the tools don't share a context
>>>>
>>>> 7. no API for apps; the framework is made up of an enormous number of
>>>> classes that follow a bunch of different "patterns" (in
>>>> quotes because the use of the term is generous) because of various
>>>> people "cleaning" things up over time (also in quotes because
>>>> the use of the term is generous), and there is no distinction between
>>>> the API that apps are intended to use and the internal
>>>> implementation of that API; this has the nasty side effect of making it
>>>> difficult to find the object and method you want, AND it
>>>> makes backward compatibility problems REALLY nasty because it gets
>>>> people believing that EVERY SINGLE object needs to ALWAYS be
>>>> backward compatible... and that results in more and more piles of trash
>>>> code lying around over time, and all of that code and
>>>> differing patterns makes framework changes error-prone and unnecessarily
>>>> difficult (and this is true for some of the app code in
>>>> OFBiz too)
>>>>
>>>> I should get back to work... there's a short list anyway...
>>>>
>>>> The trick is how to solve these without abandoning backward
>>>> compatibility, and requiring a refactor of much of the framework and
>>>> then based on that the updating of massive numbers of application
>>>> artifacts... and that is just the stuff in OFBiz itself... not
>>>> including everything that everyone else has written outside the project
>>>> that they may want to update. And, ALL of that would
>>>> have to be retested. Plus, it would take so long to get all of this done
>>>> in a branch with huge numbers of changes while others
>>>> are making incremental changes in the trunk making it nearly impossible
>>>> to merge the branch into the trunk, so it would
>>>> basically be a fork anyway...
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>
>>
>>
>
>

[Jacques Le Roux]

From: "Pierre Smits" <[hidden email]>
> If we have the consensus, a documented approach and the structure in place
> the participants will follow. Some of current community will step out and
> new enthousiast will get on board.
>
> What do you mean with 'better control of code access permissions'?

David expressed he is partially unsatisfied with the move we did when arriving at Apache. Now all committers have write access to
all parts of OFBiz, before it was more restricted (fine grained access rights).

Jacques

> Anyway, I am, and always have been, willing to participate and support
> change for the better.
>
> Regards,
>
> Pierre
>
> 2011/1/26 Jacques Le Roux <[hidden email]>
>
>> From: "Jacopo Cappellato" <[hidden email]>
>>
>>  There are so many interesting topics in this thread and for now I will
>>> comment on few of them (in spare order):
>>>
>>> 1) backward compatibility: we already have to stable release branches (and
>>> we will probably create another one soon) and users can
>>> use them and be sure that future releases *within* the branch will be
>>> backward compatible; I mean that 10.04.01, 10.04.02,
>>> 10.04.03 etc... will be backward compatible with 10.04 but not with the
>>> 09.04 series; future release branches can (and in my
>>> opinion *should*) be free to break backward compatibility; of course the
>>> community, or even better, commercial vendors could
>>> create migration scripts for, let's say, users of 09.04 series to help
>>> them migrate t the 10.04 series; but this is not something
>>> that the community *has* to do; it is important that the history behind
>>> OFBiz is treated as a valuable asset of the project and
>>> not as an burden; to summarize: backward compatibility should be
>>> considered only for the commits of a given release branch and
>>> should not be a limitation for development in the trunk
>>>
>>
>> The migration scripts idea (especially if commercial vendors are involved)
>> is a very good idea. This could foster an ecosystem
>> around OFBiz with differenret versions still compatible. Even without it, I
>> think going the Tomcat way (as David outlined, or HTTPD
>> also) would relieve us of the burden of updating endlessly versions. It's
>> already the case, the verion 4.0 is ignored by us, we
>> don't update it
>> anymore. I have even created a specific Jira for valuable R4.0 patches
>> https://issues.apache.org/jira/browse/OFBIZ-3268
>>
>>
>>  2) refactoring the OFBiz framework: I would be very happy to discuss and
>>> implement a newer version of the framework; I think that
>>> we should get a much lighter framework working into the following
>>> directions:
>>> 2.0) before any action can be taken we should finally find an agreement
>>> for a definition of the framework; what is it? how should
>>> be used? IMO something like "a framework for building ERP applications
>>> (characterized by extensive relational data model and
>>> several business processes that manage the data) with browser friendly ui"
>>> is a good start
>>> 2.a) removing old or not used (by the official applications) artifacts and
>>> tools; ideally we should have one implementation for
>>> each tool required; alternate implementation should go away;
>>> 2.b) removing (or at least revisiting the way they have been integrated)
>>> big external chunks of other projects; they could be
>>> moved to a separate "extra" folder (possibly together with part of the 2.a
>>> stuff), not built by default and not included in our
>>> official releases (instead they could be released separately)
>>> 2.c) enhance/simplify the tools we want to keep based on the features/best
>>> practices that proved their validity in the history of
>>> the project (in an evolutionary context)
>>> 2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the
>>> official applications to reflect the changes in the framework
>>> (more about this in point 2.e)
>>> 2.e) application and special purpose components: at some point we may
>>> realize that, in order to reflect the changes in the
>>> framework, it would be easier to rewrite/refactor (part of) them instead
>>> of updating them; at that point we may create a
>>> freeze/branch of OFBiz and remove the applications from the trunk; then
>>> migrate to the trunk the parts that we want to keep in the
>>> new generation OFBiz; we could even end up with a completely different
>>> structure like: one component for the generic ERP
>>> application (combining together part of several existing applications like
>>> party, product, order etc... that are already
>>> interdependent) plus a series of vertical components (still rather
>>> generic); or one generic component containing generic business
>>> logic (services) and data models for a generic ERP and then several
>>> different components with different ui for different
>>> industries (like one for retailers, one for manufacturers etc...)
>>>
>>
>> Good ideas, but I'm afraid we still lack human ressources for this to
>> happen, at least at short/mid term. Also one David point (even
>> if not in the 7 list) is he wants a better control of code access
>> permissions...
>>
>>
>>  3) issues with bureaucracy: it is definitely true that being part of the
>>> ASF oblige us to follow and respect some rules; this is
>>> sometime a pain, especially when the rules conflicts with the greater good
>>> of the project (see for example the issues with the ASF
>>> resources that we were forced to adopt); however I don't think that the
>>> issues we see in the community and in OFBiz are caused by
>>> this or by the PMC; I think that the main issues are caused by the
>>> attitude of people working in the community, by conflicting
>>> goals and expectations, by the lack of a shared goal (or by the hidden
>>> presence of several conflicting personal goals), by the
>>> huge size of OFBiz and by its long history; these are indeed issues that
>>> we have to tackle and try to resolve together with a
>>> positive attitude but they could happen in every other big group of people
>>> working with different goals on the same shared
>>> resource; we should not blame the ASF or the PMC for this
>>>
>>
>> I can't agree more. Note though that infra team has been kind enough to
>> double our memory ressources recently. It was a bit of work
>> to convince them, but they are open and happy to help, not a blind
>> bureaucracy! Now, since almost a month, we have *any issues* with
>> the demo instances, and I'm very happy with that.
>>
>> Most of the time we have to be patient when a conflict occurs between
>> committers. It's often limited human ressources and pressure
>> of time which raises those conflicts, Zen attitude helps then (I speak for
>> myself ;o). But we should never forget those issues when
>> they arise and discuss as much as needed. Else one day they come back with
>> more force and sometimes it's too late to handle them.
>>
>> My 2cts
>>
>> Jacques
>>
>>
>>  Kind regards,
>>>
>>> Jacopo
>>>
>>> On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
>>>
>>>  Many of the things listed here have been discussed, and as far as I can
>>>> tell, there is no objection to making those changes - we
>>>> just need the manpower to do it.
>>>>
>>>> Item #7 has been discussed and there hasn't been any argument against
>>>> that change - except that it touches on the
>>>> backwards-compatibility issue. And I'm going to use this opportunity to
>>>> address that issue.
>>>>
>>>> Some of the changes mentioned here wouldn't affect any of my projects -
>>>> because I don't attempt to patch or modify the
>>>> framework - I only build applications on it. Other changes mentioned here
>>>> would make application development easier.
>>>>
>>>> The other day Ryan Foster described the backwards-compatibility talk as a
>>>> mantra. I view it as more of a straw man. Five days ago
>>>> I posed this question to the user mailing list:
>>>>
>>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could
>>>> be improved greatly - but at the cost of some backward
>>>> incompatibility - accept the changes? If yes, how often would
>>>> backwards-incompatible changes be acceptable?"
>>>>
>>>> It is interesting to note that in a list of over 400 subscribers, no one
>>>> has replied.
>>>>
>>>> The most vocal proponents of backwards-compatibility (in the framework)
>>>> are a few players who have modified the framework
>>>> locally. As a community, do we really want to allow those few members to
>>>> stifle innovation?
>>>>
>>>> Some users claimed the updated Flat Grey visual theme wasn't "backwards
>>>> compatible."  What does that even mean? Some colors and
>>>> background images were changed - how is that backwards incompatible?
>>>>
>>>> To be fair, I have been an advocate for backwards-compatibility. But that
>>>> has been for things that break application
>>>> functionality.
>>>>
>>>> At the least, there needs to be a compromise. At best, there needs to be
>>>> acceptance of the possibility of future versions that
>>>> are not backwards compatible with previous versions. That concept is not
>>>> new or revolutionary - it goes on in every software
>>>> project, both open source and commercial.
>>>>
>>>> David has some great ideas, but he feels compelled to start over from
>>>> scratch to implement them. From my perspective, that's a
>>>> tragedy. One of the project's founders feels the need to start another
>>>> project as a last resort to make the project he originally
>>>> started better. Does that make sense?
>>>>
>>>> I don't want to use Moqui. It's an unfinished framework controlled by one
>>>> person and it has no applications built around it.
>>>> Bottom line - it's not an option. What I want is  Moqui's innovations in
>>>> OFBiz.
>>>>
>>>> I believe it's time we have a serious discussion about this. Users have
>>>> commented that there is no plan for OFBiz - what is
>>>> planned for its future? They're right. Maybe we should come up with some
>>>> plans, or some kind of path to the future.
>>>>
>>>> I propose we put all the cards on the table. Where do we go from here?
>>>> Continue on our present path and have competing projects
>>>> that improve on OFBiz technology?  Try to keep innovation in the project
>>>> at the expense of some backwards incompatibility?
>>>> Maintain backwards compatibility by forking the project to something new?
>>>> Or have milestone versions that are clearly marketed as
>>>> backwards incompatible with previous milestone versions?
>>>>
>>>> Lately, it seems many of the big players in the OFBiz developer community
>>>> have been absent on the mailing list. I understand that
>>>> this is a volunteer community, but at the same time, we all have a say,
>>>> and that "say" depends on us saying *something.*
>>>>
>>>> So, please say something.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>>
>>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>>
>>>>>  On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>>
>>>>>>> All of that said, now that Moqui is starting to take shape I find the
>>>>>>> OFBiz Framework to be cumbersome and inconsistent in
>>>>>>> many ways (things that are hard to fix, but that are not surprising
>>>>>>> given the pioneering history of the OFBiz Framework).
>>>>>>> Those funny quirky things are likely a turn-off to prospective
>>>>>>> developers and I'm hoping to remove that impediment to adopting
>>>>>>> the approach.
>>>>>>>
>>>>>> David - you keep saying this..Please provide some examples of
>>>>>> "cumbersome and inconsistent" within the framework. And why not
>>>>>> try and fix these? Instead of reinventing the wheel. What "funny
>>>>>> quirky" things have turned of prospective developers? Do you
>>>>>> have an specific examples?
>>>>>>
>>>>> Yes, I have mentioned these many times especially in the last 2-3 years.
>>>>> Some of them I have tried to fix in OFBiz itself and
>>>>> ran into rather large problems. These are not easy changes to make in a
>>>>> large and mature project like OFBiz, and after trying a
>>>>> few times I decided that a new framework was the only way forward
>>>>> (another thing I've written before and made very clear).
>>>>>
>>>>> These are the things that led to many aspects of the design of Moqui,
>>>>> and the best summary of them is the document I wrote about
>>>>> the differences between the Moqui and OFBiz frameworks:
>>>>>
>>>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>>
>>>>> To sum up here are some of the major inconsistencies and annoyances in
>>>>> the current OFBiz framework that bug me frequently while
>>>>> I'm developing:
>>>>>
>>>>> 1. XML actions are different in each widget and in the simple-methods;
>>>>> they share some underlying code but there are so many
>>>>> differences
>>>>>
>>>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL,
>>>>> and Groovy and keeping track of which is a pain, plus
>>>>> the Groovy syntax and capabilities are SO much better than the others so
>>>>> I find myself almost always using ${groovy:...} instead
>>>>> of the default, and in annoying places like the form.field.@use-whenattribute since it is always BeanShell I just use a set
>>>>> action to prepare a boolean and then check it in the use-when (BeanShell
>>>>> is HORRIBLE compared to groovy, especially when
>>>>> squeezed into XML attributes)
>>>>>
>>>>> 3. the controller.xml file gets HUGE for larger applications, and if
>>>>> split it becomes harder to find requests and views;
>>>>> *Screen.xml files also tend to get HUGE with large numbers of screens in
>>>>> them; both are not organized in the same way as the
>>>>> application, also generally making things harder to find; views/screens
>>>>> and requests don't define incoming parameters so when
>>>>> doing request-redirect you have to specify the parameters to use in a
>>>>> larger number of places
>>>>>
>>>>> 4. another on the topic of why so many files: service groups and
>>>>> simple-methods are just XML, why not include them inline in the
>>>>> service definition (especially for smaller services), and encourage
>>>>> fewer services per file
>>>>>
>>>>> 5. loading of artifacts is not very lazy, meaning lots of unused
>>>>> screens, forms, services, entities and so on that are not used
>>>>> are loaded anyway; also many artifacts are difficult to reload by cache
>>>>> clearing and so that has limited support in OFBiz; this
>>>>> slows things down reloading lots of stuff in development, and results in
>>>>> more resources used than needed in production
>>>>>
>>>>> 6. the deployment model of OFBiz is limited and the use of static fields
>>>>> for initialization makes it difficult to deploy in
>>>>> other ways; there are few init/destroy methods and object instances that
>>>>> would make more deployment models easier and more
>>>>> flexible; also because of this it is difficult to get data from other
>>>>> parts of the framework (for example the audit log stuff in
>>>>> the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId
>>>>> and visitId down since there is no other good way of
>>>>> doing it); in other words, the tools don't share a context
>>>>>
>>>>> 7. no API for apps; the framework is made up of an enormous number of
>>>>> classes that follow a bunch of different "patterns" (in
>>>>> quotes because the use of the term is generous) because of various
>>>>> people "cleaning" things up over time (also in quotes because
>>>>> the use of the term is generous), and there is no distinction between
>>>>> the API that apps are intended to use and the internal
>>>>> implementation of that API; this has the nasty side effect of making it
>>>>> difficult to find the object and method you want, AND it
>>>>> makes backward compatibility problems REALLY nasty because it gets
>>>>> people believing that EVERY SINGLE object needs to ALWAYS be
>>>>> backward compatible... and that results in more and more piles of trash
>>>>> code lying around over time, and all of that code and
>>>>> differing patterns makes framework changes error-prone and unnecessarily
>>>>> difficult (and this is true for some of the app code in
>>>>> OFBiz too)
>>>>>
>>>>> I should get back to work... there's a short list anyway...
>>>>>
>>>>> The trick is how to solve these without abandoning backward
>>>>> compatibility, and requiring a refactor of much of the framework and
>>>>> then based on that the updating of massive numbers of application
>>>>> artifacts... and that is just the stuff in OFBiz itself... not
>>>>> including everything that everyone else has written outside the project
>>>>> that they may want to update. And, ALL of that would
>>>>> have to be retested. Plus, it would take so long to get all of this done
>>>>> in a branch with huge numbers of changes while others
>>>>> are making incremental changes in the trunk making it nearly impossible
>>>>> to merge the branch into the trunk, so it would
>>>>> basically be a fork anyway...
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>

[Pierre Smits]

IMO that has more to do with following established procedures and guidelines
and educating committers. And sticking to them. Reverting when code has been
implemented when not being agreed upon. It might be a pain in the beginning,
but proving it worth in the end.

I know that ASF allows discretionary actions by committers, but is it not so
that the PMC is to oversee those actions?

2011/1/26 Jacques Le Roux <[hidden email]>

> From: "Pierre Smits" <[hidden email]>
>
>  If we have the consensus, a documented approach and the structure in place
>> the participants will follow. Some of current community will step out and
>> new enthousiast will get on board.
>>
>> What do you mean with 'better control of code access permissions'?
>>
>
> David expressed he is partially unsatisfied with the move we did when
> arriving at Apache. Now all committers have write access to all parts of
> OFBiz, before it was more restricted (fine grained access rights).
>
> Jacques
>
>
>> Anyway, I am, and always have been, willing to participate and support
>> change for the better.
>>
>> Regards,
>>
>> Pierre
>>
>> 2011/1/26 Jacques Le Roux <[hidden email]>
>>
>>  From: "Jacopo Cappellato" <[hidden email]>
>>>
>>>  There are so many interesting topics in this thread and for now I will
>>>
>>>> comment on few of them (in spare order):
>>>>
>>>> 1) backward compatibility: we already have to stable release branches
>>>> (and
>>>> we will probably create another one soon) and users can
>>>> use them and be sure that future releases *within* the branch will be
>>>> backward compatible; I mean that 10.04.01, 10.04.02,
>>>> 10.04.03 etc... will be backward compatible with 10.04 but not with the
>>>> 09.04 series; future release branches can (and in my
>>>> opinion *should*) be free to break backward compatibility; of course the
>>>> community, or even better, commercial vendors could
>>>> create migration scripts for, let's say, users of 09.04 series to help
>>>> them migrate t the 10.04 series; but this is not something
>>>> that the community *has* to do; it is important that the history behind
>>>> OFBiz is treated as a valuable asset of the project and
>>>> not as an burden; to summarize: backward compatibility should be
>>>> considered only for the commits of a given release branch and
>>>> should not be a limitation for development in the trunk
>>>>
>>>>
>>> The migration scripts idea (especially if commercial vendors are
>>> involved)
>>> is a very good idea. This could foster an ecosystem
>>> around OFBiz with differenret versions still compatible. Even without it,
>>> I
>>> think going the Tomcat way (as David outlined, or HTTPD
>>> also) would relieve us of the burden of updating endlessly versions. It's
>>> already the case, the verion 4.0 is ignored by us, we
>>> don't update it
>>> anymore. I have even created a specific Jira for valuable R4.0 patches
>>> https://issues.apache.org/jira/browse/OFBIZ-3268
>>>
>>>
>>>  2) refactoring the OFBiz framework: I would be very happy to discuss and
>>>
>>>> implement a newer version of the framework; I think that
>>>> we should get a much lighter framework working into the following
>>>> directions:
>>>> 2.0) before any action can be taken we should finally find an agreement
>>>> for a definition of the framework; what is it? how should
>>>> be used? IMO something like "a framework for building ERP applications
>>>> (characterized by extensive relational data model and
>>>> several business processes that manage the data) with browser friendly
>>>> ui"
>>>> is a good start
>>>> 2.a) removing old or not used (by the official applications) artifacts
>>>> and
>>>> tools; ideally we should have one implementation for
>>>> each tool required; alternate implementation should go away;
>>>> 2.b) removing (or at least revisiting the way they have been integrated)
>>>> big external chunks of other projects; they could be
>>>> moved to a separate "extra" folder (possibly together with part of the
>>>> 2.a
>>>> stuff), not built by default and not included in our
>>>> official releases (instead they could be released separately)
>>>> 2.c) enhance/simplify the tools we want to keep based on the
>>>> features/best
>>>> practices that proved their validity in the history of
>>>> the project (in an evolutionary context)
>>>> 2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the
>>>> official applications to reflect the changes in the framework
>>>> (more about this in point 2.e)
>>>> 2.e) application and special purpose components: at some point we may
>>>> realize that, in order to reflect the changes in the
>>>> framework, it would be easier to rewrite/refactor (part of) them instead
>>>> of updating them; at that point we may create a
>>>> freeze/branch of OFBiz and remove the applications from the trunk; then
>>>> migrate to the trunk the parts that we want to keep in the
>>>> new generation OFBiz; we could even end up with a completely different
>>>> structure like: one component for the generic ERP
>>>> application (combining together part of several existing applications
>>>> like
>>>> party, product, order etc... that are already
>>>> interdependent) plus a series of vertical components (still rather
>>>> generic); or one generic component containing generic business
>>>> logic (services) and data models for a generic ERP and then several
>>>> different components with different ui for different
>>>> industries (like one for retailers, one for manufacturers etc...)
>>>>
>>>>
>>> Good ideas, but I'm afraid we still lack human ressources for this to
>>> happen, at least at short/mid term. Also one David point (even
>>> if not in the 7 list) is he wants a better control of code access
>>> permissions...
>>>
>>>
>>>  3) issues with bureaucracy: it is definitely true that being part of the
>>>
>>>> ASF oblige us to follow and respect some rules; this is
>>>> sometime a pain, especially when the rules conflicts with the greater
>>>> good
>>>> of the project (see for example the issues with the ASF
>>>> resources that we were forced to adopt); however I don't think that the
>>>> issues we see in the community and in OFBiz are caused by
>>>> this or by the PMC; I think that the main issues are caused by the
>>>> attitude of people working in the community, by conflicting
>>>> goals and expectations, by the lack of a shared goal (or by the hidden
>>>> presence of several conflicting personal goals), by the
>>>> huge size of OFBiz and by its long history; these are indeed issues that
>>>> we have to tackle and try to resolve together with a
>>>> positive attitude but they could happen in every other big group of
>>>> people
>>>> working with different goals on the same shared
>>>> resource; we should not blame the ASF or the PMC for this
>>>>
>>>>
>>> I can't agree more. Note though that infra team has been kind enough to
>>> double our memory ressources recently. It was a bit of work
>>> to convince them, but they are open and happy to help, not a blind
>>> bureaucracy! Now, since almost a month, we have *any issues* with
>>> the demo instances, and I'm very happy with that.
>>>
>>> Most of the time we have to be patient when a conflict occurs between
>>> committers. It's often limited human ressources and pressure
>>> of time which raises those conflicts, Zen attitude helps then (I speak
>>> for
>>> myself ;o). But we should never forget those issues when
>>> they arise and discuss as much as needed. Else one day they come back
>>> with
>>> more force and sometimes it's too late to handle them.
>>>
>>> My 2cts
>>>
>>> Jacques
>>>
>>>
>>>  Kind regards,
>>>
>>>>
>>>> Jacopo
>>>>
>>>> On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
>>>>
>>>>  Many of the things listed here have been discussed, and as far as I can
>>>>
>>>>> tell, there is no objection to making those changes - we
>>>>> just need the manpower to do it.
>>>>>
>>>>> Item #7 has been discussed and there hasn't been any argument against
>>>>> that change - except that it touches on the
>>>>> backwards-compatibility issue. And I'm going to use this opportunity to
>>>>> address that issue.
>>>>>
>>>>> Some of the changes mentioned here wouldn't affect any of my projects -
>>>>> because I don't attempt to patch or modify the
>>>>> framework - I only build applications on it. Other changes mentioned
>>>>> here
>>>>> would make application development easier.
>>>>>
>>>>> The other day Ryan Foster described the backwards-compatibility talk as
>>>>> a
>>>>> mantra. I view it as more of a straw man. Five days ago
>>>>> I posed this question to the user mailing list:
>>>>>
>>>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project
>>>>> could
>>>>> be improved greatly - but at the cost of some backward
>>>>> incompatibility - accept the changes? If yes, how often would
>>>>> backwards-incompatible changes be acceptable?"
>>>>>
>>>>> It is interesting to note that in a list of over 400 subscribers, no
>>>>> one
>>>>> has replied.
>>>>>
>>>>> The most vocal proponents of backwards-compatibility (in the framework)
>>>>> are a few players who have modified the framework
>>>>> locally. As a community, do we really want to allow those few members
>>>>> to
>>>>> stifle innovation?
>>>>>
>>>>> Some users claimed the updated Flat Grey visual theme wasn't "backwards
>>>>> compatible."  What does that even mean? Some colors and
>>>>> background images were changed - how is that backwards incompatible?
>>>>>
>>>>> To be fair, I have been an advocate for backwards-compatibility. But
>>>>> that
>>>>> has been for things that break application
>>>>> functionality.
>>>>>
>>>>> At the least, there needs to be a compromise. At best, there needs to
>>>>> be
>>>>> acceptance of the possibility of future versions that
>>>>> are not backwards compatible with previous versions. That concept is
>>>>> not
>>>>> new or revolutionary - it goes on in every software
>>>>> project, both open source and commercial.
>>>>>
>>>>> David has some great ideas, but he feels compelled to start over from
>>>>> scratch to implement them. From my perspective, that's a
>>>>> tragedy. One of the project's founders feels the need to start another
>>>>> project as a last resort to make the project he originally
>>>>> started better. Does that make sense?
>>>>>
>>>>> I don't want to use Moqui. It's an unfinished framework controlled by
>>>>> one
>>>>> person and it has no applications built around it.
>>>>> Bottom line - it's not an option. What I want is  Moqui's innovations
>>>>> in
>>>>> OFBiz.
>>>>>
>>>>> I believe it's time we have a serious discussion about this. Users have
>>>>> commented that there is no plan for OFBiz - what is
>>>>> planned for its future? They're right. Maybe we should come up with
>>>>> some
>>>>> plans, or some kind of path to the future.
>>>>>
>>>>> I propose we put all the cards on the table. Where do we go from here?
>>>>> Continue on our present path and have competing projects
>>>>> that improve on OFBiz technology?  Try to keep innovation in the
>>>>> project
>>>>> at the expense of some backwards incompatibility?
>>>>> Maintain backwards compatibility by forking the project to something
>>>>> new?
>>>>> Or have milestone versions that are clearly marketed as
>>>>> backwards incompatible with previous milestone versions?
>>>>>
>>>>> Lately, it seems many of the big players in the OFBiz developer
>>>>> community
>>>>> have been absent on the mailing list. I understand that
>>>>> this is a volunteer community, but at the same time, we all have a say,
>>>>> and that "say" depends on us saying *something.*
>>>>>
>>>>> So, please say something.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>>>
>>>>>  On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>>>
>>>>>>  On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>>
>>>>>>>
>>>>>>>  All of that said, now that Moqui is starting to take shape I find
>>>>>>>> the
>>>>>>>> OFBiz Framework to be cumbersome and inconsistent in
>>>>>>>> many ways (things that are hard to fix, but that are not surprising
>>>>>>>> given the pioneering history of the OFBiz Framework).
>>>>>>>> Those funny quirky things are likely a turn-off to prospective
>>>>>>>> developers and I'm hoping to remove that impediment to adopting
>>>>>>>> the approach.
>>>>>>>>
>>>>>>>>  David - you keep saying this..Please provide some examples of
>>>>>>> "cumbersome and inconsistent" within the framework. And why not
>>>>>>> try and fix these? Instead of reinventing the wheel. What "funny
>>>>>>> quirky" things have turned of prospective developers? Do you
>>>>>>> have an specific examples?
>>>>>>>
>>>>>>>  Yes, I have mentioned these many times especially in the last 2-3
>>>>>> years.
>>>>>> Some of them I have tried to fix in OFBiz itself and
>>>>>> ran into rather large problems. These are not easy changes to make in
>>>>>> a
>>>>>> large and mature project like OFBiz, and after trying a
>>>>>> few times I decided that a new framework was the only way forward
>>>>>> (another thing I've written before and made very clear).
>>>>>>
>>>>>> These are the things that led to many aspects of the design of Moqui,
>>>>>> and the best summary of them is the document I wrote about
>>>>>> the differences between the Moqui and OFBiz frameworks:
>>>>>>
>>>>>>
>>>>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>>>
>>>>>> To sum up here are some of the major inconsistencies and annoyances in
>>>>>> the current OFBiz framework that bug me frequently while
>>>>>> I'm developing:
>>>>>>
>>>>>> 1. XML actions are different in each widget and in the simple-methods;
>>>>>> they share some underlying code but there are so many
>>>>>> differences
>>>>>>
>>>>>> 2. scriptlets and expressions are a messy combination of BeanShell,
>>>>>> UEL,
>>>>>> and Groovy and keeping track of which is a pain, plus
>>>>>> the Groovy syntax and capabilities are SO much better than the others
>>>>>> so
>>>>>> I find myself almost always using ${groovy:...} instead
>>>>>> of the default, and in annoying places like the
>>>>>> form.field.@use-whenattribute since it is always BeanShell I just use
>>>>>> a set
>>>>>>
>>>>>> action to prepare a boolean and then check it in the use-when
>>>>>> (BeanShell
>>>>>> is HORRIBLE compared to groovy, especially when
>>>>>> squeezed into XML attributes)
>>>>>>
>>>>>> 3. the controller.xml file gets HUGE for larger applications, and if
>>>>>> split it becomes harder to find requests and views;
>>>>>> *Screen.xml files also tend to get HUGE with large numbers of screens
>>>>>> in
>>>>>> them; both are not organized in the same way as the
>>>>>> application, also generally making things harder to find;
>>>>>> views/screens
>>>>>> and requests don't define incoming parameters so when
>>>>>> doing request-redirect you have to specify the parameters to use in a
>>>>>> larger number of places
>>>>>>
>>>>>> 4. another on the topic of why so many files: service groups and
>>>>>> simple-methods are just XML, why not include them inline in the
>>>>>> service definition (especially for smaller services), and encourage
>>>>>> fewer services per file
>>>>>>
>>>>>> 5. loading of artifacts is not very lazy, meaning lots of unused
>>>>>> screens, forms, services, entities and so on that are not used
>>>>>> are loaded anyway; also many artifacts are difficult to reload by
>>>>>> cache
>>>>>> clearing and so that has limited support in OFBiz; this
>>>>>> slows things down reloading lots of stuff in development, and results
>>>>>> in
>>>>>> more resources used than needed in production
>>>>>>
>>>>>> 6. the deployment model of OFBiz is limited and the use of static
>>>>>> fields
>>>>>> for initialization makes it difficult to deploy in
>>>>>> other ways; there are few init/destroy methods and object instances
>>>>>> that
>>>>>> would make more deployment models easier and more
>>>>>> flexible; also because of this it is difficult to get data from other
>>>>>> parts of the framework (for example the audit log stuff in
>>>>>> the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId
>>>>>> and visitId down since there is no other good way of
>>>>>> doing it); in other words, the tools don't share a context
>>>>>>
>>>>>> 7. no API for apps; the framework is made up of an enormous number of
>>>>>> classes that follow a bunch of different "patterns" (in
>>>>>> quotes because the use of the term is generous) because of various
>>>>>> people "cleaning" things up over time (also in quotes because
>>>>>> the use of the term is generous), and there is no distinction between
>>>>>> the API that apps are intended to use and the internal
>>>>>> implementation of that API; this has the nasty side effect of making
>>>>>> it
>>>>>> difficult to find the object and method you want, AND it
>>>>>> makes backward compatibility problems REALLY nasty because it gets
>>>>>> people believing that EVERY SINGLE object needs to ALWAYS be
>>>>>> backward compatible... and that results in more and more piles of
>>>>>> trash
>>>>>> code lying around over time, and all of that code and
>>>>>> differing patterns makes framework changes error-prone and
>>>>>> unnecessarily
>>>>>> difficult (and this is true for some of the app code in
>>>>>> OFBiz too)
>>>>>>
>>>>>> I should get back to work... there's a short list anyway...
>>>>>>
>>>>>> The trick is how to solve these without abandoning backward
>>>>>> compatibility, and requiring a refactor of much of the framework and
>>>>>> then based on that the updating of massive numbers of application
>>>>>> artifacts... and that is just the stuff in OFBiz itself... not
>>>>>> including everything that everyone else has written outside the
>>>>>> project
>>>>>> that they may want to update. And, ALL of that would
>>>>>> have to be retested. Plus, it would take so long to get all of this
>>>>>> done
>>>>>> in a branch with huge numbers of changes while others
>>>>>> are making incremental changes in the trunk making it nearly
>>>>>> impossible
>>>>>> to merge the branch into the trunk, so it would
>>>>>> basically be a fork anyway...
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>

[Adrian Crum-3]

Jacopo,

Your suggestions sound fair to me. Maybe after the 11.x branch is
created we can discuss these ideas.

-Adrian

On 1/26/2011 2:11 AM, Jacopo Cappellato wrote:

> There are so many interesting topics in this thread and for now I will comment on few of them (in spare order):
>
> 1) backward compatibility: we already have to stable release branches (and we will probably create another one soon) and users can use them and be sure that future releases *within* the branch will be backward compatible; I mean that 10.04.01, 10.04.02, 10.04.03 etc... will be backward compatible with 10.04 but not with the 09.04 series; future release branches can (and in my opinion *should*) be free to break backward compatibility; of course the community, or even better, commercial vendors could create migration scripts for, let's say, users of 09.04 series to help them migrate t the 10.04 series; but this is not something that the community *has* to do; it is important that the history behind OFBiz is treated as a valuable asset of the project and not as an burden; to summarize: backward compatibility should be considered only for the commits of a given release branch and should not be a limitation for development in the trunk
>
> 2) refactoring the OFBiz framework: I would be very happy to discuss and implement a newer version of the framework; I think that we should get a much lighter framework working into the following directions:
> 2.0) before any action can be taken we should finally find an agreement for a definition of the framework; what is it? how should be used? IMO something like "a framework for building ERP applications (characterized by extensive relational data model and several business processes that manage the data) with browser friendly ui" is a good start
> 2.a) removing old or not used (by the official applications) artifacts and tools; ideally we should have one implementation for each tool required; alternate implementation should go away;
> 2.b) removing (or at least revisiting the way they have been integrated) big external chunks of other projects; they could be moved to a separate "extra" folder (possibly together with part of the 2.a stuff), not built by default and not included in our official releases (instead they could be released separately)
> 2.c) enhance/simplify the tools we want to keep based on the features/best practices that proved their validity in the history of the project (in an evolutionary context)
> 2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the official applications to reflect the changes in the framework (more about this in point 2.e)
> 2.e) application and special purpose components: at some point we may realize that, in order to reflect the changes in the framework, it would be easier to rewrite/refactor (part of) them instead of updating them; at that point we may create a freeze/branch of OFBiz and remove the applications from the trunk; then migrate to the trunk the parts that we want to keep in the new generation OFBiz; we could even end up with a completely different structure like: one component for the generic ERP application (combining together part of several existing applications like party, product, order etc... that are already interdependent) plus a series of vertical components (still rather generic); or one generic component containing generic business logic (services) and data models for a generic ERP and then several different components with different ui for different industries (like one for retailers, one for manufacturers etc...)
>
> 3) issues with bureaucracy: it is definitely true that being part of the ASF oblige us to follow and respect some rules; this is sometime a pain, especially when the rules conflicts with the greater good of the project (see for example the issues with the ASF resources that we were forced to adopt); however I don't think that the issues we see in the community and in OFBiz are caused by this or by the PMC; I think that the main issues are caused by the attitude of people working in the community, by conflicting goals and expectations, by the lack of a shared goal (or by the hidden presence of several conflicting personal goals), by the huge size of OFBiz and by its long history; these are indeed issues that we have to tackle and try to resolve together with a positive attitude but they could happen in every other big group of people working with different goals on the same shared resource; we should not blame the ASF or the PMC for this
>
> Kind regards,
>
> Jacopo
>
> On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
>
>> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we just need the manpower to do it.
>>
>> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>>
>> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the framework - I only build applications on it. Other changes mentioned here would make application development easier.
>>
>> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago I posed this question to the user mailing list:
>>
>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>>
>> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>>
>> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework locally. As a community, do we really want to allow those few members to stifle innovation?
>>
>> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and background images were changed - how is that backwards incompatible?
>>
>> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application functionality.
>>
>> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software project, both open source and commercial.
>>
>> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally started better. Does that make sense?
>>
>> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it. Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>>
>> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>>
>> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility? Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as backwards incompatible with previous milestone versions?
>>
>> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>>
>> So, please say something.
>>
>> -Adrian
>>
>>
>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>
>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>>
>>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>>
>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>
>>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>>
>>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>>
>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>>
>>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>>
>>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>>
>>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>>
>>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>>
>>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>>
>>> I should get back to work... there's a short list anyway...
>>>
>>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>>
>>> -David
>>>
>>>

[David E. Jones-2]

I'll respond here to Adrian's comments below, and to what Raj and others have written as well.

Backwards compatibility is a huge issue, but I suppose that is as much a symptom as it is a disease in and of itself. The underlying issue is bureaucracy.

If I wanted to spend all my time chatting with others and writing endlessly about when to do things and what to do, and trying to recruit others to do it... then OFBiz would be the perfect place for that. I did that for years, and I'm happy with what has been done with OFBiz, but there came a point in time where the whole bureaucratic trend became stronger than any single person's ability to push for new or different things. That point in time was at least a yeah and a half ago, and perhaps long earlier than that depending on how you look at it.

Personally, I'd rather spend my time on more productive efforts, and do so in a way that avoids this same bureaucratic mess in the future (like different management style and keeping framework, data model, themes, and applications as separate projects). This way not only I, but many people are free to work on what they want to and not have to argue about every little thing they want to do, or deal with constant complaints about every little thing they actually do.

Isn't separate and competing projects better than that everyone arguing and having to agree on what to do? Well, I have good news! No matter how you (the reader) answer that question, you have an option to fit your preferences.

-David


On Jan 25, 2011, at 8:45 PM, Adrian Crum wrote:

> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we just need the manpower to do it.
>
> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>
> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the framework - I only build applications on it. Other changes mentioned here would make application development easier.
>
> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago I posed this question to the user mailing list:
>
> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>
> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>
> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework locally. As a community, do we really want to allow those few members to stifle innovation?
>
> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and background images were changed - how is that backwards incompatible?
>
> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application functionality.
>
> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software project, both open source and commercial.
>
> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally started better. Does that make sense?
>
> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it. Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>
> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>
> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility? Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as backwards incompatible with previous milestone versions?
>
> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>
> So, please say something.
>
> -Adrian
>
>
> On 1/25/2011 1:53 PM, David E Jones wrote:
>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>
>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>
>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>
>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>
>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>
>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>
>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>
>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>
>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>
>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>
>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>
>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>
>> I should get back to work... there's a short list anyway...
>>
>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>
>> -David
>>
>>
>

[David E. Jones-2]

Adrian,

Thanks for writing this. It is an excellent example of the paradigm of bureaucracy in action.

-David


On Jan 26, 2011, at 6:21 AM, Adrian Crum wrote:

> Jacopo,
>
> Your suggestions sound fair to me. Maybe after the 11.x branch is created we can discuss these ideas.
>
> -Adrian
>
> On 1/26/2011 2:11 AM, Jacopo Cappellato wrote:
>> There are so many interesting topics in this thread and for now I will comment on few of them (in spare order):
>>
>> 1) backward compatibility: we already have to stable release branches (and we will probably create another one soon) and users can use them and be sure that future releases *within* the branch will be backward compatible; I mean that 10.04.01, 10.04.02, 10.04.03 etc... will be backward compatible with 10.04 but not with the 09.04 series; future release branches can (and in my opinion *should*) be free to break backward compatibility; of course the community, or even better, commercial vendors could create migration scripts for, let's say, users of 09.04 series to help them migrate t the 10.04 series; but this is not something that the community *has* to do; it is important that the history behind OFBiz is treated as a valuable asset of the project and not as an burden; to summarize: backward compatibility should be considered only for the commits of a given release branch and should not be a limitation for development in the trunk
>>
>> 2) refactoring the OFBiz framework: I would be very happy to discuss and implement a newer version of the framework; I think that we should get a much lighter framework working into the following directions:
>> 2.0) before any action can be taken we should finally find an agreement for a definition of the framework; what is it? how should be used? IMO something like "a framework for building ERP applications (characterized by extensive relational data model and several business processes that manage the data) with browser friendly ui" is a good start
>> 2.a) removing old or not used (by the official applications) artifacts and tools; ideally we should have one implementation for each tool required; alternate implementation should go away;
>> 2.b) removing (or at least revisiting the way they have been integrated) big external chunks of other projects; they could be moved to a separate "extra" folder (possibly together with part of the 2.a stuff), not built by default and not included in our official releases (instead they could be released separately)
>> 2.c) enhance/simplify the tools we want to keep based on the features/best practices that proved their validity in the history of the project (in an evolutionary context)
>> 2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the official applications to reflect the changes in the framework (more about this in point 2.e)
>> 2.e) application and special purpose components: at some point we may realize that, in order to reflect the changes in the framework, it would be easier to rewrite/refactor (part of) them instead of updating them; at that point we may create a freeze/branch of OFBiz and remove the applications from the trunk; then migrate to the trunk the parts that we want to keep in the new generation OFBiz; we could even end up with a completely different structure like: one component for the generic ERP application (combining together part of several existing applications like party, product, order etc... that are already interdependent) plus a series of vertical components (still rather generic); or one generic component containing generic business logic (services) and data models for a generic ERP and then several different components with different ui for different industries (like one for retailers, one for manufacturers etc...)
>>
>> 3) issues with bureaucracy: it is definitely true that being part of the ASF oblige us to follow and respect some rules; this is sometime a pain, especially when the rules conflicts with the greater good of the project (see for example the issues with the ASF resources that we were forced to adopt); however I don't think that the issues we see in the community and in OFBiz are caused by this or by the PMC; I think that the main issues are caused by the attitude of people working in the community, by conflicting goals and expectations, by the lack of a shared goal (or by the hidden presence of several conflicting personal goals), by the huge size of OFBiz and by its long history; these are indeed issues that we have to tackle and try to resolve together with a positive attitude but they could happen in every other big group of people working with different goals on the same shared resource; we should not blame the ASF or the PMC for this
>>
>> Kind regards,
>>
>> Jacopo
>>
>> On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
>>
>>> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we just need the manpower to do it.
>>>
>>> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>>>
>>> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the framework - I only build applications on it. Other changes mentioned here would make application development easier.
>>>
>>> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago I posed this question to the user mailing list:
>>>
>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>>>
>>> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>>>
>>> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework locally. As a community, do we really want to allow those few members to stifle innovation?
>>>
>>> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and background images were changed - how is that backwards incompatible?
>>>
>>> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application functionality.
>>>
>>> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software project, both open source and commercial.
>>>
>>> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally started better. Does that make sense?
>>>
>>> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it. Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>>>
>>> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>>>
>>> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility? Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as backwards incompatible with previous milestone versions?
>>>
>>> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>>>
>>> So, please say something.
>>>
>>> -Adrian
>>>
>>>
>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>
>>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>>>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>>>
>>>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>>>
>>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>
>>>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>>>
>>>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>>>
>>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>>>
>>>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>>>
>>>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>>>
>>>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>>>
>>>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>>>
>>>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>>>
>>>> I should get back to work... there's a short list anyway...
>>>>
>>>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>>>
>>>> -David
>>>>
>>>>
>

[Adrian Crum-3]

I'm not sure what you mean by that. From my perspective, we're having a
discussion. Is discussion inherently bureaucratic?

-Adrian

On 1/26/2011 10:48 PM, David E Jones wrote:

> Adrian,
>
> Thanks for writing this. It is an excellent example of the paradigm of bureaucracy in action.
>
> -David
>
>
> On Jan 26, 2011, at 6:21 AM, Adrian Crum wrote:
>
>> Jacopo,
>>
>> Your suggestions sound fair to me. Maybe after the 11.x branch is created we can discuss these ideas.
>>
>> -Adrian
>>
>> On 1/26/2011 2:11 AM, Jacopo Cappellato wrote:
>>> There are so many interesting topics in this thread and for now I will comment on few of them (in spare order):
>>>
>>> 1) backward compatibility: we already have to stable release branches (and we will probably create another one soon) and users can use them and be sure that future releases *within* the branch will be backward compatible; I mean that 10.04.01, 10.04.02, 10.04.03 etc... will be backward compatible with 10.04 but not with the 09.04 series; future release branches can (and in my opinion *should*) be free to break backward compatibility; of course the community, or even better, commercial vendors could create migration scripts for, let's say, users of 09.04 series to help them migrate t the 10.04 series; but this is not something that the community *has* to do; it is important that the history behind OFBiz is treated as a valuable asset of the project and not as an burden; to summarize: backward compatibility should be considered only for the commits of a given release branch and should not be a limitation for development in the trunk
>>>
>>> 2) refactoring the OFBiz framework: I would be very happy to discuss and implement a newer version of the framework; I think that we should get a much lighter framework working into the following directions:
>>> 2.0) before any action can be taken we should finally find an agreement for a definition of the framework; what is it? how should be used? IMO something like "a framework for building ERP applications (characterized by extensive relational data model and several business processes that manage the data) with browser friendly ui" is a good start
>>> 2.a) removing old or not used (by the official applications) artifacts and tools; ideally we should have one implementation for each tool required; alternate implementation should go away;
>>> 2.b) removing (or at least revisiting the way they have been integrated) big external chunks of other projects; they could be moved to a separate "extra" folder (possibly together with part of the 2.a stuff), not built by default and not included in our official releases (instead they could be released separately)
>>> 2.c) enhance/simplify the tools we want to keep based on the features/best practices that proved their validity in the history of the project (in an evolutionary context)
>>> 2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the official applications to reflect the changes in the framework (more about this in point 2.e)
>>> 2.e) application and special purpose components: at some point we may realize that, in order to reflect the changes in the framework, it would be easier to rewrite/refactor (part of) them instead of updating them; at that point we may create a freeze/branch of OFBiz and remove the applications from the trunk; then migrate to the trunk the parts that we want to keep in the new generation OFBiz; we could even end up with a completely different structure like: one component for the generic ERP application (combining together part of several existing applications like party, product, order etc... that are already interdependent) plus a series of vertical components (still rather generic); or one generic component containing generic business logic (services) and data models for a generic ERP and then several different components with different ui for different industries (like one for retailers, one for manufacturers etc...)
>>>
>>> 3) issues with bureaucracy: it is definitely true that being part of the ASF oblige us to follow and respect some rules; this is sometime a pain, especially when the rules conflicts with the greater good of the project (see for example the issues with the ASF resources that we were forced to adopt); however I don't think that the issues we see in the community and in OFBiz are caused by this or by the PMC; I think that the main issues are caused by the attitude of people working in the community, by conflicting goals and expectations, by the lack of a shared goal (or by the hidden presence of several conflicting personal goals), by the huge size of OFBiz and by its long history; these are indeed issues that we have to tackle and try to resolve together with a positive attitude but they could happen in every other big group of people working with different goals on the same shared resource; we should not blame the ASF or the PMC for this
>>>
>>> Kind regards,
>>>
>>> Jacopo
>>>
>>> On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
>>>
>>>> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we just need the manpower to do it.
>>>>
>>>> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>>>>
>>>> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the framework - I only build applications on it. Other changes mentioned here would make application development easier.
>>>>
>>>> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago I posed this question to the user mailing list:
>>>>
>>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>>>>
>>>> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>>>>
>>>> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework locally. As a community, do we really want to allow those few members to stifle innovation?
>>>>
>>>> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and background images were changed - how is that backwards incompatible?
>>>>
>>>> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application functionality.
>>>>
>>>> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software project, both open source and commercial.
>>>>
>>>> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally started better. Does that make sense?
>>>>
>>>> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it. Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>>>>
>>>> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>>>>
>>>> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility? Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as backwards incompatible with previous milestone versions?
>>>>
>>>> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>>>>
>>>> So, please say something.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>>
>>>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>>>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>>>>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>>>>
>>>>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>>>>
>>>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>>
>>>>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>>>>
>>>>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>>>>
>>>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>>>>
>>>>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>>>>
>>>>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>>>>
>>>>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>>>>
>>>>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>>>>
>>>>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>>>>
>>>>> I should get back to work... there's a short list anyway...
>>>>>
>>>>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>>>>
>>>>> -David
>>>>>
>>>>>

[David E. Jones-2]

No, the discussion is not, but your response here is "inherently bureaucratic".

You wrote: "Your suggestions sound fair to me. Maybe after the 11.x branch is created we can discuss these ideas."

That's some serious push-back... MAYBE after the 11.x branch we can DISCUSS these ideas?

Hints at bureaucracy are still bureaucracy.

To take this to its logical conclusion: "Following the 11.x branch, which is a date not yet decided, the Committee will consider the discussion of your ideas. Should the Committee decide that discussion of said ideas is not in the best interest of the Project, the Committee will not discuss your ideas. The Committee does not consider the discussion of any idea from any source to be a commitment to act on said idea. The Committee hereby reserves the right to complain and push back and if necessary commit-war against any idea deemed improper or not in the best interest of the Project. The Committee further hereby disclaims any official status regarding these statements."

This is a great definition of the term from Wikipedia: "organization characterized by hierarchy, fixed rules, impersonal relationships, rigid adherence to procedures, and a highly specialized division of labor."

Is that a clear enough explanation of the community patterns I find less than desirable?

-David


On Jan 26, 2011, at 10:56 PM, Adrian Crum wrote:

> I'm not sure what you mean by that. From my perspective, we're having a discussion. Is discussion inherently bureaucratic?
>
> -Adrian
>
> On 1/26/2011 10:48 PM, David E Jones wrote:
>> Adrian,
>>
>> Thanks for writing this. It is an excellent example of the paradigm of bureaucracy in action.
>>
>> -David
>>
>>
>> On Jan 26, 2011, at 6:21 AM, Adrian Crum wrote:
>>
>>> Jacopo,
>>>
>>> Your suggestions sound fair to me. Maybe after the 11.x branch is created we can discuss these ideas.
>>>
>>> -Adrian
>>>
>>> On 1/26/2011 2:11 AM, Jacopo Cappellato wrote:
>>>> There are so many interesting topics in this thread and for now I will comment on few of them (in spare order):
>>>>
>>>> 1) backward compatibility: we already have to stable release branches (and we will probably create another one soon) and users can use them and be sure that future releases *within* the branch will be backward compatible; I mean that 10.04.01, 10.04.02, 10.04.03 etc... will be backward compatible with 10.04 but not with the 09.04 series; future release branches can (and in my opinion *should*) be free to break backward compatibility; of course the community, or even better, commercial vendors could create migration scripts for, let's say, users of 09.04 series to help them migrate t the 10.04 series; but this is not something that the community *has* to do; it is important that the history behind OFBiz is treated as a valuable asset of the project and not as an burden; to summarize: backward compatibility should be considered only for the commits of a given release branch and should not be a limitation for development in the trunk
>>>>
>>>> 2) refactoring the OFBiz framework: I would be very happy to discuss and implement a newer version of the framework; I think that we should get a much lighter framework working into the following directions:
>>>> 2.0) before any action can be taken we should finally find an agreement for a definition of the framework; what is it? how should be used? IMO something like "a framework for building ERP applications (characterized by extensive relational data model and several business processes that manage the data) with browser friendly ui" is a good start
>>>> 2.a) removing old or not used (by the official applications) artifacts and tools; ideally we should have one implementation for each tool required; alternate implementation should go away;
>>>> 2.b) removing (or at least revisiting the way they have been integrated) big external chunks of other projects; they could be moved to a separate "extra" folder (possibly together with part of the 2.a stuff), not built by default and not included in our official releases (instead they could be released separately)
>>>> 2.c) enhance/simplify the tools we want to keep based on the features/best practices that proved their validity in the history of the project (in an evolutionary context)
>>>> 2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the official applications to reflect the changes in the framework (more about this in point 2.e)
>>>> 2.e) application and special purpose components: at some point we may realize that, in order to reflect the changes in the framework, it would be easier to rewrite/refactor (part of) them instead of updating them; at that point we may create a freeze/branch of OFBiz and remove the applications from the trunk; then migrate to the trunk the parts that we want to keep in the new generation OFBiz; we could even end up with a completely different structure like: one component for the generic ERP application (combining together part of several existing applications like party, product, order etc... that are already interdependent) plus a series of vertical components (still rather generic); or one generic component containing generic business logic (services) and data models for a generic ERP and then several different components with different ui for different industries (like one for retailers, one for manufacturers etc...)
>>>>
>>>> 3) issues with bureaucracy: it is definitely true that being part of the ASF oblige us to follow and respect some rules; this is sometime a pain, especially when the rules conflicts with the greater good of the project (see for example the issues with the ASF resources that we were forced to adopt); however I don't think that the issues we see in the community and in OFBiz are caused by this or by the PMC; I think that the main issues are caused by the attitude of people working in the community, by conflicting goals and expectations, by the lack of a shared goal (or by the hidden presence of several conflicting personal goals), by the huge size of OFBiz and by its long history; these are indeed issues that we have to tackle and try to resolve together with a positive attitude but they could happen in every other big group of people working with different goals on the same shared resource; we should not blame the ASF or the PMC for this
>>>>
>>>> Kind regards,
>>>>
>>>> Jacopo
>>>>
>>>> On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
>>>>
>>>>> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we just need the manpower to do it.
>>>>>
>>>>> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>>>>>
>>>>> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the framework - I only build applications on it. Other changes mentioned here would make application development easier.
>>>>>
>>>>> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago I posed this question to the user mailing list:
>>>>>
>>>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>>>>>
>>>>> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>>>>>
>>>>> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework locally. As a community, do we really want to allow those few members to stifle innovation?
>>>>>
>>>>> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and background images were changed - how is that backwards incompatible?
>>>>>
>>>>> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application functionality.
>>>>>
>>>>> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software project, both open source and commercial.
>>>>>
>>>>> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally started better. Does that make sense?
>>>>>
>>>>> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it. Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>>>>>
>>>>> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>>>>>
>>>>> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility? Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as backwards incompatible with previous milestone versions?
>>>>>
>>>>> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>>>>>
>>>>> So, please say something.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>>>
>>>>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>>>>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>>>>>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>>>>>
>>>>>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>>>>>
>>>>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>>>
>>>>>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>>>>>
>>>>>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>>>>>
>>>>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>>>>>
>>>>>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>>>>>
>>>>>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>>>>>
>>>>>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>>>>>
>>>>>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>>>>>
>>>>>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>>>>>
>>>>>> I should get back to work... there's a short list anyway...
>>>>>>
>>>>>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>

[Jacopo Cappellato-4]

I have noticed some negative trends happening to us in the last (1-2) years:
* a dramatic decrease of design discussions and an increase in commits
* committers are often working for themselves and not for the greater good of the project ("if a customer pays me to do something then it will be also good for the project")
* less peer reviews and mostly focused on formal aspects rather then fundamental aspects of the contributions
* a decrease in the minimum quality level needed to make a commit "acceptable"
* a proliferation of "best practices" and "rules" in an attempt to improve the quality of the commits
* a decay in the attitude and quality of discussions: attacks, critics and fights instead of healthy discussions to learn from others and improve design decisions

Of course I am focusing on bad things, to the good ones (yes, there are also good ones) it is easier to adjust: however when the final result of our efforts is that a person like David doesn't feel comfortable in contributing more then I feel bad.
The primary goal of the PMC, and the community in general, should be that of creating the perfect environment to facilitate contributions from people like David, and limit/review/improve the contributions from other less blessed contributors: it seems like all our efforts are obtaining the exact opposite result.

Jacopo

On Jan 27, 2011, at 7:46 AM, David E Jones wrote:

>
> I'll respond here to Adrian's comments below, and to what Raj and others have written as well.
>
> Backwards compatibility is a huge issue, but I suppose that is as much a symptom as it is a disease in and of itself. The underlying issue is bureaucracy.
>
> If I wanted to spend all my time chatting with others and writing endlessly about when to do things and what to do, and trying to recruit others to do it... then OFBiz would be the perfect place for that. I did that for years, and I'm happy with what has been done with OFBiz, but there came a point in time where the whole bureaucratic trend became stronger than any single person's ability to push for new or different things. That point in time was at least a yeah and a half ago, and perhaps long earlier than that depending on how you look at it.
>
> Personally, I'd rather spend my time on more productive efforts, and do so in a way that avoids this same bureaucratic mess in the future (like different management style and keeping framework, data model, themes, and applications as separate projects). This way not only I, but many people are free to work on what they want to and not have to argue about every little thing they want to do, or deal with constant complaints about every little thing they actually do.
>
> Isn't separate and competing projects better than that everyone arguing and having to agree on what to do? Well, I have good news! No matter how you (the reader) answer that question, you have an option to fit your preferences.
>
> -David
>
>
> On Jan 25, 2011, at 8:45 PM, Adrian Crum wrote:
>
>> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we just need the manpower to do it.
>>
>> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>>
>> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the framework - I only build applications on it. Other changes mentioned here would make application development easier.
>>
>> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago I posed this question to the user mailing list:
>>
>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>>
>> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>>
>> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework locally. As a community, do we really want to allow those few members to stifle innovation?
>>
>> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and background images were changed - how is that backwards incompatible?
>>
>> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application functionality.
>>
>> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software project, both open source and commercial.
>>
>> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally started better. Does that make sense?
>>
>> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it. Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>>
>> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>>
>> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility? Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as backwards incompatible with previous milestone versions?
>>
>> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>>
>> So, please say something.
>>
>> -Adrian
>>
>>
>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>
>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>>
>>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>>
>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>
>>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>>
>>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>>
>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>>
>>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>>
>>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>>
>>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>>
>>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>>
>>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>>
>>> I should get back to work... there's a short list anyway...
>>>
>>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>>
>>> -David
>>>
>>>
>>
>

[Jacopo Cappellato-4]

Thank you Adrian.
Yes, I think that issuing another release branch before the switch would be a good idea; I am pretty sure that an important decision like this will take some good time before it is widely accepted :-)

Jacopo

On Jan 26, 2011, at 3:21 PM, Adrian Crum wrote:

> Jacopo,
>
> Your suggestions sound fair to me. Maybe after the 11.x branch is created we can discuss these ideas.
>
> -Adrian
>
> On 1/26/2011 2:11 AM, Jacopo Cappellato wrote:
>> There are so many interesting topics in this thread and for now I will comment on few of them (in spare order):
>>
>> 1) backward compatibility: we already have to stable release branches (and we will probably create another one soon) and users can use them and be sure that future releases *within* the branch will be backward compatible; I mean that 10.04.01, 10.04.02, 10.04.03 etc... will be backward compatible with 10.04 but not with the 09.04 series; future release branches can (and in my opinion *should*) be free to break backward compatibility; of course the community, or even better, commercial vendors could create migration scripts for, let's say, users of 09.04 series to help them migrate t the 10.04 series; but this is not something that the community *has* to do; it is important that the history behind OFBiz is treated as a valuable asset of the project and not as an burden; to summarize: backward compatibility should be considered only for the commits of a given release branch and should not be a limitation for development in the trunk
>>
>> 2) refactoring the OFBiz framework: I would be very happy to discuss and implement a newer version of the framework; I think that we should get a much lighter framework working into the following directions:
>> 2.0) before any action can be taken we should finally find an agreement for a definition of the framework; what is it? how should be used? IMO something like "a framework for building ERP applications (characterized by extensive relational data model and several business processes that manage the data) with browser friendly ui" is a good start
>> 2.a) removing old or not used (by the official applications) artifacts and tools; ideally we should have one implementation for each tool required; alternate implementation should go away;
>> 2.b) removing (or at least revisiting the way they have been integrated) big external chunks of other projects; they could be moved to a separate "extra" folder (possibly together with part of the 2.a stuff), not built by default and not included in our official releases (instead they could be released separately)
>> 2.c) enhance/simplify the tools we want to keep based on the features/best practices that proved their validity in the history of the project (in an evolutionary context)
>> 2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the official applications to reflect the changes in the framework (more about this in point 2.e)
>> 2.e) application and special purpose components: at some point we may realize that, in order to reflect the changes in the framework, it would be easier to rewrite/refactor (part of) them instead of updating them; at that point we may create a freeze/branch of OFBiz and remove the applications from the trunk; then migrate to the trunk the parts that we want to keep in the new generation OFBiz; we could even end up with a completely different structure like: one component for the generic ERP application (combining together part of several existing applications like party, product, order etc... that are already interdependent) plus a series of vertical components (still rather generic); or one generic component containing generic business logic (services) and data models for a generic ERP and then several different components with different ui for different industries (like one for retailers, one for manufacturers etc...)
>>
>> 3) issues with bureaucracy: it is definitely true that being part of the ASF oblige us to follow and respect some rules; this is sometime a pain, especially when the rules conflicts with the greater good of the project (see for example the issues with the ASF resources that we were forced to adopt); however I don't think that the issues we see in the community and in OFBiz are caused by this or by the PMC; I think that the main issues are caused by the attitude of people working in the community, by conflicting goals and expectations, by the lack of a shared goal (or by the hidden presence of several conflicting personal goals), by the huge size of OFBiz and by its long history; these are indeed issues that we have to tackle and try to resolve together with a positive attitude but they could happen in every other big group of people working with different goals on the same shared resource; we should not blame the ASF or the PMC for this
>>
>> Kind regards,
>>
>> Jacopo
>>
>> On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
>>
>>> Many of the things listed here have been discussed, and as far as I can tell, there is no objection to making those changes - we just need the manpower to do it.
>>>
>>> Item #7 has been discussed and there hasn't been any argument against that change - except that it touches on the backwards-compatibility issue. And I'm going to use this opportunity to address that issue.
>>>
>>> Some of the changes mentioned here wouldn't affect any of my projects - because I don't attempt to patch or modify the framework - I only build applications on it. Other changes mentioned here would make application development easier.
>>>
>>> The other day Ryan Foster described the backwards-compatibility talk as a mantra. I view it as more of a straw man. Five days ago I posed this question to the user mailing list:
>>>
>>> "Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly - but at the cost of some backward incompatibility - accept the changes? If yes, how often would backwards-incompatible changes be acceptable?"
>>>
>>> It is interesting to note that in a list of over 400 subscribers, no one has replied.
>>>
>>> The most vocal proponents of backwards-compatibility (in the framework) are a few players who have modified the framework locally. As a community, do we really want to allow those few members to stifle innovation?
>>>
>>> Some users claimed the updated Flat Grey visual theme wasn't "backwards compatible."  What does that even mean? Some colors and background images were changed - how is that backwards incompatible?
>>>
>>> To be fair, I have been an advocate for backwards-compatibility. But that has been for things that break application functionality.
>>>
>>> At the least, there needs to be a compromise. At best, there needs to be acceptance of the possibility of future versions that are not backwards compatible with previous versions. That concept is not new or revolutionary - it goes on in every software project, both open source and commercial.
>>>
>>> David has some great ideas, but he feels compelled to start over from scratch to implement them. From my perspective, that's a tragedy. One of the project's founders feels the need to start another project as a last resort to make the project he originally started better. Does that make sense?
>>>
>>> I don't want to use Moqui. It's an unfinished framework controlled by one person and it has no applications built around it. Bottom line - it's not an option. What I want is  Moqui's innovations in OFBiz.
>>>
>>> I believe it's time we have a serious discussion about this. Users have commented that there is no plan for OFBiz - what is planned for its future? They're right. Maybe we should come up with some plans, or some kind of path to the future.
>>>
>>> I propose we put all the cards on the table. Where do we go from here? Continue on our present path and have competing projects that improve on OFBiz technology?  Try to keep innovation in the project at the expense of some backwards incompatibility? Maintain backwards compatibility by forking the project to something new? Or have milestone versions that are clearly marketed as backwards incompatible with previous milestone versions?
>>>
>>> Lately, it seems many of the big players in the OFBiz developer community have been absent on the mailing list. I understand that this is a volunteer community, but at the same time, we all have a say, and that "say" depends on us saying *something.*
>>>
>>> So, please say something.
>>>
>>> -Adrian
>>>
>>>
>>> On 1/25/2011 1:53 PM, David E Jones wrote:
>>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
>>>>
>>>>> On 1/25/11 2:06 AM, David E Jones wrote:
>>>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>>>> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?
>>>> Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).
>>>>
>>>> These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:
>>>>
>>>> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
>>>>
>>>> To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:
>>>>
>>>> 1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences
>>>>
>>>> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)
>>>>
>>>> 3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places
>>>>
>>>> 4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file
>>>>
>>>> 5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production
>>>>
>>>> 6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context
>>>>
>>>> 7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)
>>>>
>>>> I should get back to work... there's a short list anyway...
>>>>
>>>> The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...
>>>>
>>>> -David
>>>>
>>>>
>

[Pierre Smits]

Maybe now the time is ripe to take the discussion regarding the road ahead
further and split it into new threads with topics that enable us to focus
and have healthy and constructive discussions.

So that we indeed can get to a workable and accepted plan for upcoming
releases of the product and an inspired and committed community.

Regards,

Pierre


2011/1/27 Jacopo Cappellato <[hidden email]>

> Thank you Adrian.
> Yes, I think that issuing another release branch before the switch would be
> a good idea; I am pretty sure that an important decision like this will take
> some good time before it is widely accepted :-)
>
> Jacopo
>
> On Jan 26, 2011, at 3:21 PM, Adrian Crum wrote:
>
> > Jacopo,
> >
> > Your suggestions sound fair to me. Maybe after the 11.x branch is created
> we can discuss these ideas.
> >
> > -Adrian
> >
> > On 1/26/2011 2:11 AM, Jacopo Cappellato wrote:
> >> There are so many interesting topics in this thread and for now I will
> comment on few of them (in spare order):
> >>
> >> 1) backward compatibility: we already have to stable release branches
> (and we will probably create another one soon) and users can use them and be
> sure that future releases *within* the branch will be backward compatible; I
> mean that 10.04.01, 10.04.02, 10.04.03 etc... will be backward compatible
> with 10.04 but not with the 09.04 series; future release branches can (and
> in my opinion *should*) be free to break backward compatibility; of course
> the community, or even better, commercial vendors could create migration
> scripts for, let's say, users of 09.04 series to help them migrate t the
> 10.04 series; but this is not something that the community *has* to do; it
> is important that the history behind OFBiz is treated as a valuable asset of
> the project and not as an burden; to summarize: backward compatibility
> should be considered only for the commits of a given release branch and
> should not be a limitation for development in the trunk
> >>
> >> 2) refactoring the OFBiz framework: I would be very happy to discuss and
> implement a newer version of the framework; I think that we should get a
> much lighter framework working into the following directions:
> >> 2.0) before any action can be taken we should finally find an agreement
> for a definition of the framework; what is it? how should be used? IMO
> something like "a framework for building ERP applications (characterized by
> extensive relational data model and several business processes that manage
> the data) with browser friendly ui" is a good start
> >> 2.a) removing old or not used (by the official applications) artifacts
> and tools; ideally we should have one implementation for each tool required;
> alternate implementation should go away;
> >> 2.b) removing (or at least revisiting the way they have been integrated)
> big external chunks of other projects; they could be moved to a separate
> "extra" folder (possibly together with part of the 2.a stuff), not built by
> default and not included in our official releases (instead they could be
> released separately)
> >> 2.c) enhance/simplify the tools we want to keep based on the
> features/best practices that proved their validity in the history of the
> project (in an evolutionary context)
> >> 2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the
> official applications to reflect the changes in the framework (more about
> this in point 2.e)
> >> 2.e) application and special purpose components: at some point we may
> realize that, in order to reflect the changes in the framework, it would be
> easier to rewrite/refactor (part of) them instead of updating them; at that
> point we may create a freeze/branch of OFBiz and remove the applications
> from the trunk; then migrate to the trunk the parts that we want to keep in
> the new generation OFBiz; we could even end up with a completely different
> structure like: one component for the generic ERP application (combining
> together part of several existing applications like party, product, order
> etc... that are already interdependent) plus a series of vertical components
> (still rather generic); or one generic component containing generic business
> logic (services) and data models for a generic ERP and then several
> different components with different ui for different industries (like one
> for retailers, one for manufacturers etc...)
> >>
> >> 3) issues with bureaucracy: it is definitely true that being part of the
> ASF oblige us to follow and respect some rules; this is sometime a pain,
> especially when the rules conflicts with the greater good of the project
> (see for example the issues with the ASF resources that we were forced to
> adopt); however I don't think that the issues we see in the community and in
> OFBiz are caused by this or by the PMC; I think that the main issues are
> caused by the attitude of people working in the community, by conflicting
> goals and expectations, by the lack of a shared goal (or by the hidden
> presence of several conflicting personal goals), by the huge size of OFBiz
> and by its long history; these are indeed issues that we have to tackle and
> try to resolve together with a positive attitude but they could happen in
> every other big group of people working with different goals on the same
> shared resource; we should not blame the ASF or the PMC for this
> >>
> >> Kind regards,
> >>
> >> Jacopo
> >>
> >> On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
> >>
> >>> Many of the things listed here have been discussed, and as far as I can
> tell, there is no objection to making those changes - we just need the
> manpower to do it.
> >>>
> >>> Item #7 has been discussed and there hasn't been any argument against
> that change - except that it touches on the backwards-compatibility issue.
> And I'm going to use this opportunity to address that issue.
> >>>
> >>> Some of the changes mentioned here wouldn't affect any of my projects -
> because I don't attempt to patch or modify the framework - I only build
> applications on it. Other changes mentioned here would make application
> development easier.
> >>>
> >>> The other day Ryan Foster described the backwards-compatibility talk as
> a mantra. I view it as more of a straw man. Five days ago I posed this
> question to the user mailing list:
> >>>
> >>> "Would you, as an end user of OFBiz, knowing that the OFBiz project
> could be improved greatly - but at the cost of some backward incompatibility
> - accept the changes? If yes, how often would backwards-incompatible changes
> be acceptable?"
> >>>
> >>> It is interesting to note that in a list of over 400 subscribers, no
> one has replied.
> >>>
> >>> The most vocal proponents of backwards-compatibility (in the framework)
> are a few players who have modified the framework locally. As a community,
> do we really want to allow those few members to stifle innovation?
> >>>
> >>> Some users claimed the updated Flat Grey visual theme wasn't "backwards
> compatible."  What does that even mean? Some colors and background images
> were changed - how is that backwards incompatible?
> >>>
> >>> To be fair, I have been an advocate for backwards-compatibility. But
> that has been for things that break application functionality.
> >>>
> >>> At the least, there needs to be a compromise. At best, there needs to
> be acceptance of the possibility of future versions that are not backwards
> compatible with previous versions. That concept is not new or revolutionary
> - it goes on in every software project, both open source and commercial.
> >>>
> >>> David has some great ideas, but he feels compelled to start over from
> scratch to implement them. From my perspective, that's a tragedy. One of the
> project's founders feels the need to start another project as a last resort
> to make the project he originally started better. Does that make sense?
> >>>
> >>> I don't want to use Moqui. It's an unfinished framework controlled by
> one person and it has no applications built around it. Bottom line - it's
> not an option. What I want is  Moqui's innovations in OFBiz.
> >>>
> >>> I believe it's time we have a serious discussion about this. Users have
> commented that there is no plan for OFBiz - what is planned for its future?
> They're right. Maybe we should come up with some plans, or some kind of path
> to the future.
> >>>
> >>> I propose we put all the cards on the table. Where do we go from here?
> Continue on our present path and have competing projects that improve on
> OFBiz technology?  Try to keep innovation in the project at the expense of
> some backwards incompatibility? Maintain backwards compatibility by forking
> the project to something new? Or have milestone versions that are clearly
> marketed as backwards incompatible with previous milestone versions?
> >>>
> >>> Lately, it seems many of the big players in the OFBiz developer
> community have been absent on the mailing list. I understand that this is a
> volunteer community, but at the same time, we all have a say, and that "say"
> depends on us saying *something.*
> >>>
> >>> So, please say something.
> >>>
> >>> -Adrian
> >>>
> >>>
> >>> On 1/25/2011 1:53 PM, David E Jones wrote:
> >>>> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
> >>>>
> >>>>> On 1/25/11 2:06 AM, David E Jones wrote:
> >>>>>> All of that said, now that Moqui is starting to take shape I find
> the OFBiz Framework to be cumbersome and inconsistent in many ways (things
> that are hard to fix, but that are not surprising given the pioneering
> history of the OFBiz Framework). Those funny quirky things are likely a
> turn-off to prospective developers and I'm hoping to remove that impediment
> to adopting the approach.
> >>>>> David - you keep saying this..Please provide some examples of
> "cumbersome and inconsistent" within the framework. And why not try and fix
> these? Instead of reinventing the wheel. What "funny quirky" things have
> turned of prospective developers? Do you have an specific examples?
> >>>> Yes, I have mentioned these many times especially in the last 2-3
> years. Some of them I have tried to fix in OFBiz itself and ran into rather
> large problems. These are not easy changes to make in a large and mature
> project like OFBiz, and after trying a few times I decided that a new
> framework was the only way forward (another thing I've written before and
> made very clear).
> >>>>
> >>>> These are the things that led to many aspects of the design of Moqui,
> and the best summary of them is the document I wrote about the differences
> between the Moqui and OFBiz frameworks:
> >>>>
> >>>>
> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
> >>>>
> >>>> To sum up here are some of the major inconsistencies and annoyances in
> the current OFBiz framework that bug me frequently while I'm developing:
> >>>>
> >>>> 1. XML actions are different in each widget and in the simple-methods;
> they share some underlying code but there are so many differences
> >>>>
> >>>> 2. scriptlets and expressions are a messy combination of BeanShell,
> UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax
> and capabilities are SO much better than the others so I find myself almost
> always using ${groovy:...} instead of the default, and in annoying places
> like the form.field.@use-when attribute since it is always BeanShell I
> just use a set action to prepare a boolean and then check it in the use-when
> (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML
> attributes)
> >>>>
> >>>> 3. the controller.xml file gets HUGE for larger applications, and if
> split it becomes harder to find requests and views; *Screen.xml files also
> tend to get HUGE with large numbers of screens in them; both are not
> organized in the same way as the application, also generally making things
> harder to find; views/screens and requests don't define incoming parameters
> so when doing request-redirect you have to specify the parameters to use in
> a larger number of places
> >>>>
> >>>> 4. another on the topic of why so many files: service groups and
> simple-methods are just XML, why not include them inline in the service
> definition (especially for smaller services), and encourage fewer services
> per file
> >>>>
> >>>> 5. loading of artifacts is not very lazy, meaning lots of unused
> screens, forms, services, entities and so on that are not used are loaded
> anyway; also many artifacts are difficult to reload by cache clearing and so
> that has limited support in OFBiz; this slows things down reloading lots of
> stuff in development, and results in more resources used than needed in
> production
> >>>>
> >>>> 6. the deployment model of OFBiz is limited and the use of static
> fields for initialization makes it difficult to deploy in other ways; there
> are few init/destroy methods and object instances that would make more
> deployment models easier and more flexible; also because of this it is
> difficult to get data from other parts of the framework (for example the
> audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to
> pass userLoginId and visitId down since there is no other good way of doing
> it); in other words, the tools don't share a context
> >>>>
> >>>> 7. no API for apps; the framework is made up of an enormous number of
> classes that follow a bunch of different "patterns" (in quotes because the
> use of the term is generous) because of various people "cleaning" things up
> over time (also in quotes because the use of the term is generous), and
> there is no distinction between the API that apps are intended to use and
> the internal implementation of that API; this has the nasty side effect of
> making it difficult to find the object and method you want, AND it makes
> backward compatibility problems REALLY nasty because it gets people
> believing that EVERY SINGLE object needs to ALWAYS be backward compatible...
> and that results in more and more piles of trash code lying around over
> time, and all of that code and differing patterns makes framework changes
> error-prone and unnecessarily difficult (and this is true for some of the
> app code in OFBiz too)
> >>>>
> >>>> I should get back to work... there's a short list anyway...
> >>>>
> >>>> The trick is how to solve these without abandoning backward
> compatibility, and requiring a refactor of much of the framework and then
> based on that the updating of massive numbers of application artifacts...
> and that is just the stuff in OFBiz itself... not including everything that
> everyone else has written outside the project that they may want to update.
> And, ALL of that would have to be retested. Plus, it would take so long to
> get all of this done in a branch with huge numbers of changes while others
> are making incremental changes in the trunk making it nearly impossible to
> merge the branch into the trunk, so it would basically be a fork anyway...
> >>>>
> >>>> -David
> >>>>
> >>>>
> >
>
>