Crudely put, but nonetheless true. And all can have their place in the OFBiz ecosystem. Even HumanRes could be considered a SpecialApp. Which of the current set of core apps should stay in? And which not? Your opinions please.
Regards, Pierre 2011/1/27 Scott Gray <scott.g...@hotwaxmedia.com> > If they have a user base then what does it matter? If people care then > they'll look after them and if not then they'll die, either way it's one > less thing to worry about. > > Regards > Scott > > HotWax Media > http://www.hotwaxmedia.com > > On 28/01/2011, at 1:03 AM, Jacques Le Roux wrote: > > > Project Manager, POS? Even maybe My Portal and AssetMaint? > > > > Jacques > > > > Scott Gray wrote: > >> 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" <pierre.sm...@gmail.com> > >>>> 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 <jacopo.cappell...@hotwaxmedia.com> > >>>>> 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 > > > > Project Manager, POS? Even maybe My Portal? > > > > Jacquees > >
