Generally I see three ways if I think of an combination of OFBiz and Moqui as already mentioned in the discussion so far:
1) „Replace“ the OFBiz Framework with Moqui 2) Replace parts of the OFBiz Framework with Moqui parts respectively update the OFBiz Framework in a Moqui manner 3) Migrate OFBiz applications and functionality, so that they be part of Mantle or standalone apps on base of Moqui Numbers 1 and 3 could lead to the same result, maybe the steps between are different or the approach or just the headline is another. Number 2 is more like thinking of optimization of the current framework, maybe by looking at Moqui, but there would be no Moqui integration in the end, only an updated OFBiz Framework. My vote for 1) is -1, because I don’t think it is a realistic project in terms of effort vs. benefit an with respect to the „customers“ of an „application framework OFBiz", this change could be an upgrade killer. For 2) there is generally a +1 where optimizations are reasonable, but this might be much less than a Moqui framework switch For 3) I say +1, also this would more be an parallel "next OFBiz“ thing Martin Becker ecomify GmbH > Am 27.04.2015 um 03:20 schrieb Adam Heath <doo...@brainfood.com>: > > "Begin replacing ..." is not an actional item. > > How can we vote on something that is ill-defined? Just saying. > > On 04/26/2015 08:09 PM, Ron Wheeler wrote: >> +1 for being too early. >> -1 for going ahead as a project >> +1 for a PoC and impact analysis >> >> Ron >> >> On 26/04/2015 6:46 PM, Pierre Smits wrote: >>> First of all, a big thanks to Adrian for taking this step, this RtV >>> (Request to Vote) to get clarity from the community. A lot has been said >>> over the last week regarding adopting a new architecture for a future >>> release. >>> >>> When discussions, like fire, die down it is good to find out where the >>> community stands. And it seems that a saturation point was reached, as the >>> last posting before Adam started to test the water of consensus was already >>> 6 days ago. >>> >>> It seems that we are facing a chicken-and-egg situation here, as we can't >>> vote on the new direction without knowing the impact of such path. And we >>> can't establish insights about the impact without having tested the water >>> and report about it. >>> >>> A PoC is a means to gain the insights. Based on the output of such an >>> action, the community can reach a well-founded decision. But a PoC is not >>> the only means to establish the insight. An in-dept comparative study of >>> the two solutions (architecture, et all) might lead to such insights too. >>> And a PoC can be done everywhere, even outside the OFBiz repository. >>> >>> The result of the impact analysis (whether from PoC or comparative study) >>> could be recorded as JIRA issues. And all the registered JIRA issues >>> together will be the starting point of a dev branch when the community >>> votes for the adoption of a new architecture or not (based on those issues >>> and other information). >>> >>> On the basis of current (high level) information regarding the impact, I >>> say it is to early to vote for a migration. >>> >>> 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 Sun, Apr 26, 2015 at 10:56 PM, Michael Brohl <michael.br...@ecomify.de> >>> wrote: >>> >>>> Thank you for the clarification. >>>> I'll stick to my vote and my arguments then. >>>> >>>> Michael Brohl >>>> ecomify GmbH >>>> www.ecomify.de >>>> >>>> Am 26.04.15 um 22:33 schrieb Adrian Crum: >>>> >>>> No, it is not a vote for a POC. If the community agrees we need to make a >>>>> change, then we can create a Jira issue, branch, POC, etc. >>>>> >>>>> No one is going to go to all that work if in the end the community says >>>>> "Nope, don't want it." >>>>> >>>>> Adrian Crum >>>>> Sandglass Software >>>>> www.sandglass-software.com >>>>> >>>>> >>>> >> >> >
