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" <[email protected]> To: [email protected] 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/%[email protected]%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" <[email protected]> > To: [email protected] > 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 < >> [email protected]> wrote: >> >>> On Apr 26, 2015, at 3:09 PM, Adrian Crum < >>> [email protected]> 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...? >>> >>> Jacopo >>> >>>> Adrian 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 thread >>> completely 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 "replace >>> OFBiz 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 < >>> [email protected]> 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 some >>> major >>>>>>> decisions.... >>>>>>> >>>>>>> Regards, >>>>>>> Hans Bakker >>>>>>> antwebsystems.com >>>>>>> >>>>>>> >>> > >
