Taher,I think the main value in OFBiz and what makes it differ a lot from other frameworks is a strong and mature framework, the comprehensive data model and a lot of business functionality in combination ootb. Naturally, OFBiz has matured over the years and contains contributions from many different developers with different skill sets and style, which leads to code with room for improvements :-)
I won't get as far as Adrian and call it old and brittle. I think that's no suitable rating for the framework state.
The maturity of OFBiz and the fact that it is used in very different, enterprise businesses all over the world is a key argument for choosing OFBiz. That's at least my experience.
I think the discussion lacks a systematic evaluation of the costs and benefits of the different migration paths. Whats's the real value in Moqui in relation to OFBiz? Is it possible to adopt some of the Moqui patterns in OFBiz without replacing it entirely? What are the pain points in OFBiz? What does it cost (time and developer resources) to do the different migrations? etc.
I think I stated it earlier: we need some kind of evaluation/decision matrix to even have a chance to decide something apart from personal taste, technological interest or whatever drives us.
That alone would be a huge effort though... Regards, Michael Brohl ecomify GmbH www.ecomify.de Am 21.05.15 um 18:07 schrieb Taher Alkhateeb:
Hi Adrian, Ahh very interesting document. I went through the document and the email from David. So it seems moqui has implemented this vision by having a monolithic framework and things build on top of it. The question still lingers and I am still not sure of the answer. If the community decides to replace the OFBiz core framework with moqui, what is the advantage in ofbiz+moqui that does not exist in moqui standalone. I find this a critical question because I have no idea what ofbiz will be like after the integration. I know today that there are thousands of entities, services, screens and scripts that cut my development time and allow me to deliver solutions quickly to the clients. So it's the _stuff_ inside ofbiz that is currently the added value, otherwise it's just another web framework. However, I am not sure if those artifacts would remain or need to be rewritten. And if they need to be rewritten, then why write them on ofbiz+moqui instead of moqui standalone which I think according to the above document is leaner and cleaner. Sorry if I'm repeating myself, I'm just trying to wrap my head around this. Taher Alkhateeb ----- Original Message ----- From: "Adrian Crum" <adrian.c...@sandglass-software.com> To: dev@ofbiz.apache.org Sent: Thursday, 21 May, 2015 5:53:39 PM Subject: Re: Discussion: Replace framework by Moqui. Actually, this discussion started 5 years ago, when David first proposed rewriting the framework. He gave a good list of reasons why it was necessary. We have been discussing it periodically since then. I tried to find the original conversation, but I was unsuccessful. It occurred somewhere between mid-to-late 2009. Here is a later discussion that was a follow up: http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3c07565c88-4023-4d24-93a3-a4906e86f...@me.com%3E In response to that email, I created this wiki page: https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision because I believed (and still believe) that our development team is capable of rewriting the framework. The discussion at ApacheCon was brief, and during that discussion I covered everything above. To summarize: The current framework code is old and brittle, making it difficult to maintain. The API is obtuse - making it difficult to use. Adrian Crum Sandglass Software www.sandglass-software.com On 5/21/2015 7:14 AM, Taher Alkhateeb wrote:Hi everyone, I spent some time reading through this thread again. I read the advantages of adopting moqui especially those mentioned by David Jones including: - smaller cleaner code base - simplified security - RESTful services - elastic search - easier learning curve for new comers - pure service layer instead of object/service hybrid - simpler order logic as the shopping cart resides in the database - there is probably more! I also read some of the objections including backward incompatibility, huge effort, dependency risk and so on. But I didn't find anywhere in this thread the _value proposition_ for this move. In other words, what value are we providing if we give ofbiz+moque instead of moqui alone? Why would people choose the ofbiz+moqui solution and not just switch to moqui? I wasn't at the ApacheCon which started this thread so maybe I'm missing something? Taher Alkhateeb ----- Original Message ----- From: "Ron Wheeler" <rwhee...@artifact-software.com> To: dev@ofbiz.apache.org Sent: Thursday, 21 May, 2015 4:28:52 PM Subject: Re: Discussion: Replace framework by Moqui. I am not a lawyer and Apache's legal team should be approached before we embark on a plan that involves the use of a third party tool that does not have an Apache license or a license that is known to be compatible with inclusion in an Apache product. At the moment, from my reading of the source that Jacques found, it would not be possible to release a Moqui-based framework under an Apache license. Moqui is in a no-man's land where your right to use it depends on what country you are in and unless you are the owner, it is not clear how your can redistribute it internationally. If we write a layer to go between Moqui and the OFBiz components to replace the framework, users would have to decide if they could legally run Moqui and would have to go get it on their own and install it separately. For the moment my preference would be to focus on getting the current framework into a separate sub-project, clean up the current dependency issues, document it and release it as a separate deliverable with an Apache license and its own roadmap and "marketing" plan. That is based on assertions from knowledgeable people in this project that it is valuable on its own for others who want to develop other sorts of business applications. Even if Moqui is a better framework technically, the Apache license would make the Apache OFBiz Framework a more desirable product for an organization wanting to invest in creating an application. Ron On 21/05/2015 4:49 AM, Scott Gray wrote:Advance cast of -1 in case I miss the vote if it ever comes. Moqui is it's own eco-system. The only way to "replace the framework with Moqui" is to rewrite the apps to be moqui apps. If that was done, what does it have to do with OFBiz@Apache? We could rename the project to Apps for Moqui and become application curators and essentially be a different project. But what's the point of doing that here rather than over at moqui? (wherever "at moqui" is) The work I think Adrian is suggesting is introducing Moqui as some sort of hybrid into OFBiz until we can phase out the OFBiz framework completely. To me that seems like a convoluted way to go instead of just rewriting the apps. Regards Scott On 27 April 2015 at 02:11, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote:On Apr 26, 2015, at 3:09 PM, Adrian Crum < adrian.c...@sandglass-software.com> wrote:How about "Replace framework core functionality - like entity engine,service engine, and security with Moqui."Is that specific enough?Not really: we have talked about bringing the whole Moqui codebase into the OFBiz trunk (bad idea in my opinion), or migrating the applications to Moqui, or reimplementing them and the sentence above doesn't specify a direction. And why entity engine, service and security and not for example transaction management, connection pooling, ui technology, logging etc...? JacopoAdrian Crum Sandglass Software www.sandglass-software.com On 4/26/2015 1:47 PM, Jacopo Cappellato wrote:The discussion is interesting and fascinating but in this threadcompletely different ideas have been expressed: from forking Moqui into OFBiz to rewriting OFBiz applications from scratch on top of Moqui etc...My vote will be negative if the vote will be as generic as "replaceOFBiz framework with Moqui" is because it would not be an actionable item and there could be 1000 totally different ways to implement it.Jacopo On Apr 26, 2015, at 1:58 PM, Adrian Crum <adrian.c...@sandglass-software.com> wrote:This has been discussed for nearly a week now. Shall we start a vote? Adrian Crum Sandglass Software www.sandglass-software.com On 4/20/2015 6:31 AM, Hans Bakker wrote:Again, as discussed at the ApacheCon in Austin we should start setting up a plan how to best move the ERP application to the Moqui framework. Moqui should not be part of the Apache foundation however the ERP application should remain there. Not only will it improve development of the ERP system but also will establish a clean separation between application and frameworks and hopefully getting David Jones back into the project. Yes, I realize i open the pandora box :-) but we need to make somemajordecisions.... Regards, Hans Bakker antwebsystems.com
smime.p7s
Description: S/MIME Cryptographic Signature
