+1 - with the clarification that to me "begin replacing" implies a PoC effort in a branch.
I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-<version>.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc - either in the Moqui runtime directory or as an OFBiz component add a "webroot" webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a "thunk" layer as Adrian proposed, probably accessing the statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes are statically initialized, or using the more dynamic initialization through the Moqui webroot webapp. For those who want a brief introduction to some of the differences between OFBiz Framework and Moqui Framework, see the "OFBiz: How does it compare to Moqui?" section at: http://www.moqui.org/framework/index.html That is an older document and isn't meant to be any sort of exhaustive list of the features of Moqui versus the features of OFBiz Framework, but gives a general idea about how some of the similar tools are different. For those who want to dive a bit deeper the Tutorial may be helpful: http://www.moqui.org/framework/docs/Tutorial.html For those who want to dive in neck deep the "Making Apps with Moqui" book is the more exhaustive reference to Moqui (though about 8 months old now and there are many new features, summarized in the ReleaseNotes.txt file for those curious): http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt I would be happy to participate in this effort... if nothing else should be an interesting technical diversion. -David > On 26 Apr 2015, at 07:44, Adrian Crum <[email protected]> > wrote: > > As was discussed last week, there is some interest in replacing some (or all) > of OFBiz with Moqui (http://www.moqui.org/framework/index.html). > > To the scope reasonable, I propose that we begin by converting the following > parts of the OFBiz framework with Moqui: > > Entity Engine > Service Engine > Security > > Other parts of the OFBiz framework could be converted as well, but I think > this would be a good starting point, and if is successful, then more of OFBiz > can be converted later. > > I believe we can create a thunk component to help solve compatibility > problems, but that is a separate discussion. I only mention it here in case > compatibility concerns might influence a vote. > > -- > Adrian Crum > Sandglass Software > www.sandglass-software.com
