I wonder what the impact will be on the apps currently available in OFBiz. Best regards,
Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Wed, Apr 29, 2015 at 4:12 AM, Hans Bakker <[email protected]> wrote: > Hi David, very good to have you back in the project! > > Exiting times ahead! > > Regards, > Hans > > > On 28/04/15 15:39, David E. Jones wrote: > >> +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 >>> >> >
