On 28/01/2011, at 12:19 AM, Pierre Smits wrote: > That sounds like a workable solution to me as well. > > But why move parts of the current code of the product (as is it is now) > outside of the ASF' repo?
Some of those points were just thrown out there, I'm not necessarily in favor of that and I don't really have any solid ideas for how to handle the core apps other than believing they should be more easily modifiable without patches. > Looking at Commons in JIRA I see several related projects. We could do this > for OFBiz too. Split up in to several sub projects, have for each sub > project a committed sub community of users, contributors and committers. And > still having interaction between all. That is definitely a possibility and has been discussed a few times in the past. The discussion never goes far because the framework separation is a better big task in itself that needs to be tackled first. > Regards, > > Pierre > > > > 2011/1/27 Jacopo Cappellato <[email protected]> > >> On Jan 27, 2011, at 11:50 AM, Scott Gray wrote: >> >>> (With so many messages I don't have a good spot to say my short piece so >> here will do) >>> >>> IMO our problems will only increase with the size of the code base. >> Every time a new feature is committed you have an additional potential >> audience that must be kept happy and our ability to please everybody >> continues to decrease. Unhappy people don't work well together so things >> just keep getting worse. >>> >>> Solution? Decrease the size of the code base and included features and >> increase the ability for the community to share contributions outside of the >> ASF's repo. Decrease the load on the committers and let the rest of the >> community put their money where their mouth is. >>> Some ideas (feasible or not): >>> - Pull out all of the themes except one and move each one to google code >> or wherever if there is someone interested in looking after each one. >>> - Then do the same for the bulk of the special purpose apps. >>> - Separate the framework from the applications. >>> - Remove any framework features that aren't used by the applications or >> are of relatively low value and allow them to be dropped in by users when >> they need them. >>> - Perhaps even take another look at the possibility of reducing the >> dependencies among the core apps and splitting them (I'd gladly welcome 100 >> new committers to the humanres app because I have no interest in it). >>> - Turn the payment and shipping gateway implementations into drop in >> components along with any other pieces of code that are suitable for >> extraction >>> - Investigate ways to allow plug-in modification of apps and implement >> something (anything) that allows it. >>> >> >> +1 on all points; the next step in the life of the project will be the >> setup of an healthy ecosystem and these are concrete steps in that >> direction. >> >> Jacopo >> >>> Right now we have a gigantic project with a gateway of ~13 active >> committers (23 total) who have day jobs to worry about along with reviewing >> (and fighting about) commits (or just giving up on this responsibility), >> attempting to improve the project and taking part in these (mostly pointless >> discussions) and then keeping the rest of the community happy. Increasing >> the number of committers just increases the potential for disagreement and >> then stagnation so the only other option to reduce the code. >>> >>> Give control of features and components to people who care about them and >> then help users find them externally as they need them. Don't like the >> direction a feature/component is taking? Fork it and compete. >>> >>> Regards >>> Scott >>> >>> On 27/01/2011, at 9:54 PM, Jacopo Cappellato wrote: >>> >>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >>
smime.p7s
Description: S/MIME cryptographic signature
