It seems weird to keep a 'demo application' in the framework, purely to facilitate developers. It adds no value to using ofbiz in production. So it should be removable from the framework and and self-contained (no dependencies from other applications).
Op 18 maart 2012 12:16 schreef <adrian.c...@sandglass-software.com> het volgende: > I think Example should stay in the framework, but get rid of all of the > "showroom" stuff that has been added to it. In other words, keep it and > return it to its original purpose - a very basic component for new users to > understand OFBiz. > > I use datafile to connect legacy systems to OFBiz. > > I agree that specialpurpose should be slimmed down, but we should retain > one or two components to demonstrate the concept of reusing artifacts to > create custom applications. > > -Adrian > > > Quoting Jacopo Cappellato > <jacopo.cappellato@**hotwaxmedia.com<jacopo.cappell...@hotwaxmedia.com> > >: > > In the last period the OFBiz project has grown a lot in shape: the >> implicitly accepted (or tolerated) strategy operated by the active >> committers was that the more features you could add to the official >> repository the better was: you make happy the contributors, making them >> feel like they are a part of something, and each committer could manage the >> code implemented for his/her own projects directly in the OFBiz codebase. >> >> We operated under the concept that, since the code if "free" and the >> author (committer or not) is willing to contribute it, then no one >> should/could complain if it is added to the repository, if it doesn't cause >> immediate problems to others; all in all it is an additional feature that >> may be used by someone else in the future or if not would simply stay there >> without causing any harm. >> Following this strategy we got a lot of code like for example Webslinger, >> seleniumxml, debian packages, all sort of specialpurpose applications etc... >> >> Since there was not a central and agreed upon roadmap, no one could >> really state that a contribution was not a good fit for the project: each >> and every committer could add what, in his own personal vision, was good >> for the project. >> >> The wrong assumption is that, since the code if "free" then it doesn't >> harm to include it. This is completely *wrong*: the code is not *free* at >> all because as soon as you add it to the repository then you add a future >> cost to the community: you all know that in the software industry the cost >> to maintain a piece of code is by far greater than the cost to write it; >> and you *have* to maintain the code unless you want to have and distribute >> stale code. >> And this is exactly what we have now: >> * high costs to maintain the code (e.g. I recently spent a lot of hours >> to remove the Webslinger component) >> * stale/unused/half baked code that causes confusion and bad impression >> to user evaluating the quality of our product >> >> The message to all the committers is: when you add code to the >> repository, you are asking the community to take care of its maintenance >> costs forever. So please, add new code only when it is really beneficial to >> the project and to a large audience of committers and users. >> >> It is like feeding a wild animal at the zoo with chips: everyone knows it >> is bad for its health but when you are there it is so nice when it picks >> the food from your own hands and you cannot resist and have to feed it. >> >> OFBiz is now suffering from serious weight issues: the committers >> community is having an hard time to maintain the huge codebase, it is >> difficult to keep track of all the features in the system etc... >> >> I think it is important to start a new phase of the project and focus our >> energy in cleanup and consolidation of what we have. One step in this >> direction is for OFBiz to lose weight. >> >> In order to get the ball rolling and focus on some concrete tasks I am >> providing here some examples of stuff that I would like to see removed from >> the project. >> >> IMPORTANT: Please consider that the list is not based on what I think the >> perfect framework should be (so PLEASE do not reply stating what your ideal >> framework should have), but simply on the following considerations: >> * can the component be easily removed by the project? is it independent >> and can live outside as a plugin? >> * do we need all this custom code? can't we find a simpler, lighter and >> better way to implement this? >> * is this feature used by other code in the system? >> * is the feature functional? or is it largely incomplete? >> * is this an old component/code? >> * is this used by a lot of persons? (this is tricky to decide but you can >> get a feeling of it by reading the mailing lists, considering commit >> activity, the status of the feature etc...) >> >> DISCLAIMER: I know it will be a painful decision because each of us >> reading this will have a connection with some of the code listed below: >> several hours spent on it, great ideas that never came to a finished plan; >> in fact I feel the same for a few of the things in the list.... there are >> great ideas that didn't come to a finalization... it doesn't mean that >> moving them out of the project will kill them and this may actually help to >> get more visibility and different user group; so please when you will read >> it... think to the greater good of the community. >> >> Legenda for what I propose for each piece of code: >> * Attic: remove from code base and document the removal for future >> reference in this page >> * Extras: identify a person interested in maintaining the code as a >> separate project hosted as an Apache Extra project (not officially under >> the ASF); add a link to it from the page that will contain "OFBiz Extras" >> >> And now (drums)..... THE LIST - PART 1(but this is really a very first >> pass only, PART 2 will come soon with more granular - subcomponent - >> details): >> >> A) move framework/guiapp out of the framework; after all these years no >> code made advantage of it being part of the framework and it is only used >> by the specialpurpose/pos component (which was the component for which it >> was built for); so guiapp can go in the pos component >> >> B) specialpurpose/pos: move to "Extras" >> >> C) $OFBIZ_HOME/debian: move to "Attic" >> >> D) the seleniumxml code in framework/testtools: move to "Attic" >> >> E) specialpurpose/workflow: move to "Attic" >> >> F) specialpurpose/shark: move to "Attic" >> >> G) specialpurpose/ofbizwebsite: move to "Attic" >> >> H) specialpurpose/*: move several (if not all, apart ecommerce) of the >> components to "Extras" (if there are persons interested to become >> committers/maintainers) or to "Attic" >> >> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them >> to "Extras"; keep just one (or two) >> >> J) framework/appserver: move to "Extras" >> >> K) framework/jetty: move to "Extras" (or "Attic") >> >> L) framework/birt (and related dependencies/reports spread around): move >> to "Extras" >> >> M) framework/bi (and related dependencies - ecas/business rules and data >> - spread around): move to "Extras" >> >> N) framework/jcr: move back into the Jackrabbit branch until the work is >> completed and can replace the existing "content framework" >> >> O) framework/documents: move the content to Wiki and then move to "Attic" >> >> P) framework/datafile: (who is currently using it?) move to "Extras" or >> "Attic"; we could replace it with commons-csv or similar tool >> >> Q) framework/example and framework/exampleext: move to specialpurpose >> >> Kind regards, >> >> Jacopo >> >> >> > > >
