I agree that ecommerce is significantly important enough that it should be kept under project control but I don't believe for a second that the other special purpose components benefit from being in the main code base except that it increases their visibility.
On 28/01/2011, at 12:34 AM, Jacques Le Roux wrote: > Another interesting idea, competing with Erwan's. I'd also prefer to keep > things in ASF repo if possible... > We could have a distinction between components, important one (eCommerce, > ...) still in ASF repo, others more peripheric, (ebay, Google, Oagis, etc.) > out of it? > > Jacques > > From: "Pierre Smits" <[email protected]> >> 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? >> >> 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. >> >> 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
