I agree with you Adrian, any major rewrites or changes are probably best done in a way to not affect the active trunk, especially when it is has been a while since a release branch and we are close to the 2011 one (we could really do it any time I support).
But, there is no reason to rush it either. If people want to work on major changes they can work on them in feature branches. Of course, some changes (like splitting out pieces of the project) are probably best done in a central place and the trunk might be best for that (after a release branch). -David On Jan 27, 2011, at 6:10 AM, Adrian Crum wrote: > Thanks - I understand now. I apologize if I over-asserted myself. > > I wasn't trying to be a bureaucrat. My suggestion wasn't push-back - it was a > suggestion based on the current level of activity in the community. It seems > everyone is really busy right now, so in my mind starting a major rewrite > could be held off until after the 11.x branch is created. If people are > available now to get started, then that's great - let's get started. > > -Adrian > > On 1/26/2011 11:56 PM, David E Jones wrote: >> 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 >>>>>>>> >>>>>>>> >
