VOTE: Begin Replacing OFBiz Framework With Moqui

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

VOTE: Begin Replacing OFBiz Framework With Moqui

Adrian Crum-3
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
Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Ron Wheeler
Is this a proposal for a POC?
If so, where will this be done and what is estimated amount of time
required to complete the POC.
What will be required to complete te conversion if the POC is successful?

What is the impact on the framework as a product if it is successful?

Ron

On 26/04/2015 10:44 AM, Adrian Crum 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.
>


--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Michael Brohl-3
In reply to this post by Adrian Crum-3
-1 (not binding)

This is *not* a vote against moving to Moqui or replacing parts of OFBiz
with Moqui or...

I simply feel there is not enough discussion, deeper insights in the
effects, a clear path how to do it etc., at least for me. I would prefer
to have some scenarios described, take a deeper look at the effects,
estimate the efforts and resources etc.

No real company would set up a project of replacing their base products'
framwork with another one based on the available informations and
estimations.

"Begin replacing OFBiz Framework With Moqui": *-1* (right now)

"Begin to organise a PoC, have a deeper discussion and gather more
facts": *+1*

Michael
ecomify GmbH
www.ecomify.de


Am 26.04.15 um 16:44 schrieb Adrian Crum:

> 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.
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Adrian Crum-3
No one is going to invest their time and effort in a POC unless they
have the approval and support of the community. I don't think you're
going to see a POC before a vote.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/26/2015 6:39 PM, Michael Brohl wrote:

> -1 (not binding)
>
> This is *not* a vote against moving to Moqui or replacing parts of OFBiz
> with Moqui or...
>
> I simply feel there is not enough discussion, deeper insights in the
> effects, a clear path how to do it etc., at least for me. I would prefer
> to have some scenarios described, take a deeper look at the effects,
> estimate the efforts and resources etc.
>
> No real company would set up a project of replacing their base products'
> framwork with another one based on the available informations and
> estimations.
>
> "Begin replacing OFBiz Framework With Moqui": *-1* (right now)
>
> "Begin to organise a PoC, have a deeper discussion and gather more
> facts": *+1*
>
> Michael
> ecomify GmbH
> www.ecomify.de
>
>
> Am 26.04.15 um 16:44 schrieb Adrian Crum:
>> 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.
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Michael Brohl-3
Adrian,

that's what I tried to say and what Ron asked: if it's a vote for a POC
and not a final decision to replace OFBiz with Moqui: +1

The vote title is not about a POC but about a decision to begin
replacing. For me this sounds like a difference. Might be a language
problem on my side.

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 26.04.15 um 21:27 schrieb Adrian Crum:

> No one is going to invest their time and effort in a POC unless they
> have the approval and support of the community. I don't think you're
> going to see a POC before a vote.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/26/2015 6:39 PM, Michael Brohl wrote:
>> -1 (not binding)
>>
>> This is *not* a vote against moving to Moqui or replacing parts of OFBiz
>> with Moqui or...
>>
>> I simply feel there is not enough discussion, deeper insights in the
>> effects, a clear path how to do it etc., at least for me. I would prefer
>> to have some scenarios described, take a deeper look at the effects,
>> estimate the efforts and resources etc.
>>
>> No real company would set up a project of replacing their base products'
>> framwork with another one based on the available informations and
>> estimations.
>>
>> "Begin replacing OFBiz Framework With Moqui": *-1* (right now)
>>
>> "Begin to organise a PoC, have a deeper discussion and gather more
>> facts": *+1*
>>
>> Michael
>> ecomify GmbH
>> www.ecomify.de
>>
>>
>> Am 26.04.15 um 16:44 schrieb Adrian Crum:
>>> 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.
>>>
>>
>>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Adrian Crum-3
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

On 4/26/2015 9:16 PM, Michael Brohl wrote:

> Adrian,
>
> that's what I tried to say and what Ron asked: if it's a vote for a POC
> and not a final decision to replace OFBiz with Moqui: +1
>
> The vote title is not about a POC but about a decision to begin
> replacing. For me this sounds like a difference. Might be a language
> problem on my side.
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> Am 26.04.15 um 21:27 schrieb Adrian Crum:
>> No one is going to invest their time and effort in a POC unless they
>> have the approval and support of the community. I don't think you're
>> going to see a POC before a vote.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/26/2015 6:39 PM, Michael Brohl wrote:
>>> -1 (not binding)
>>>
>>> This is *not* a vote against moving to Moqui or replacing parts of OFBiz
>>> with Moqui or...
>>>
>>> I simply feel there is not enough discussion, deeper insights in the
>>> effects, a clear path how to do it etc., at least for me. I would prefer
>>> to have some scenarios described, take a deeper look at the effects,
>>> estimate the efforts and resources etc.
>>>
>>> No real company would set up a project of replacing their base products'
>>> framwork with another one based on the available informations and
>>> estimations.
>>>
>>> "Begin replacing OFBiz Framework With Moqui": *-1* (right now)
>>>
>>> "Begin to organise a PoC, have a deeper discussion and gather more
>>> facts": *+1*
>>>
>>> Michael
>>> ecomify GmbH
>>> www.ecomify.de
>>>
>>>
>>> Am 26.04.15 um 16:44 schrieb Adrian Crum:
>>>> 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.
>>>>
>>>
>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Michael Brohl-3
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
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Pierre Smits
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 <[hidden email]>
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
>>
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Adam Heath-2
In reply to this post by Adrian Crum-3
On 04/26/2015 09:44 AM, Adrian Crum 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 converting0 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.
>

0: needs more discussion.
Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Adam Heath-2
In reply to this post by Adrian Crum-3
On 04/26/2015 02:27 PM, Adrian Crum wrote:
> No one is going to invest their time and effort in a POC unless they
> have the approval and support of the community. I don't think you're
> going to see a POC before a vote.
>

I would.

Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Adam Heath-2
On 04/26/2015 06:13 PM, Adam Heath wrote:
> On 04/26/2015 02:27 PM, Adrian Crum wrote:
>> No one is going to invest their time and effort in a POC unless they
>> have the approval and support of the community. I don't think you're
>> going to see a POC before a vote.
>>
>
> I would.
>
I haven't yet looked at Moqui either, so I'd be starting with a fresh
view.  This would also be a good way to get my feet wet.

And, without even looking at the code, the first goal would be to have
both running at the same time, in the same instance, with both being
able to call each others service engines, and both database layers
talking to the exact same structure.  That would allow for services to
be implemented in both, and would give a much clear incremental switchover.
Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Ron Wheeler
In reply to this post by Pierre Smits
+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 <[hidden email]>
> 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
>>>
>>>
>>


--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Adam Heath-2
"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
>> <[hidden email]>
>> 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
>>>>
>>>>
>>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Martin Becker
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 <[hidden email]>:
>
> "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 <[hidden email]>
>>> 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
>>>>>
>>>>>
>>>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

David E. Jones-2
In reply to this post by Adrian Crum-3

+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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Adrian Crum-3
This is great news! Your participation will be invaluable!

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/28/2015 9:39 AM, 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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Adam Heath-2
In reply to this post by David E. Jones-2

On 04/28/2015 03:39 AM, 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)

There are 2 separate items in this bullet point.  I'll talk about the
second, updating jar versions.

HAHAHAHAHAHAHA!

I have discovered that ofbiz is using hc.apache.org(HttpClient), and
commons-httpclient.  The former is the newer, rewritten, rearchitected,
replacement for the latter.

The rest of the versioned jars are just as bad.

> - 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

Do each of the separate moqui sub-tools need their own runtime folder?  
How difficult would it be to have $OFBIZ_HOME/runtime/$tool1,
runtime/$tool2, 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

Wait.  The webapp initializes the context factory?  There isn't a
separate way to do this?  Does that mean Moqui is tied to a webapp? What
kind of webapp?  I hope it isn't servlets.

You mention it as weboot.  Does that mean it runs at the root of the
webserver?  This might be a noob question.

> - 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)
Ah.  So that means that means that moqui-component needs a container
definition.  Ignore the above then.

I have never liked that ofbiz startup delays initialization of certain
components until they are magically called from some random bit of java
code, aka, the web container starting up.

> - 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

Sorry for the noob question, but does that mean that both ofbiz
entityengine and moqui could talk to the same database backend(s), at
the same time?

> 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.

Actually, a bit simpler, would be to just see if moqui can be added to
the classpath, and loaded, before translating any datamodels. Once that
is done, then have a method that translates the model definitions
dynamically at load time, so that they are always kept in sync.

Once this has proven, then that dynamic translation can be removed, and
the output of it can become the new static definition of the model.

The reason I suggest this way, is so that hot-deploy components(or other
file modifications) that alter the entity definitions
dynamically(extends-entity, whole new entity definitions) can also work
transparently.

> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Nicolas Malin-2
In reply to this post by Adrian Crum-3
-1 currently for me

If we are inspired of Moqui to improve OFBiz framework not to replace
it, I will review my vote.

For main framework components, I prefer keep the source code control
under this community instead of load only jar

Nicolas

Le 26/04/2015 16:44, Adrian Crum a écrit :

> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

David E. Jones-2
In reply to this post by Adam Heath-2

> On 28 Apr 2015, at 07:42, Adam Heath <[hidden email]> wrote:
>
>
> On 04/28/2015 03:39 AM, 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)
>
> There are 2 separate items in this bullet point.  I'll talk about the second, updating jar versions.
>
> HAHAHAHAHAHAHA!
>
> I have discovered that ofbiz is using hc.apache.org(HttpClient), and commons-httpclient.  The former is the newer, rewritten, rearchitected, replacement for the latter.
>
> The rest of the versioned jars are just as bad.

Sounds like a small project of its own...

>> - 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
>
> Do each of the separate moqui sub-tools need their own runtime folder?  How difficult would it be to have $OFBIZ_HOME/runtime/$tool1, runtime/$tool2, etc?

The Moqui runtime folder is similar to the one in OFBiz with component directories, and framework specific directories for classes, conf, db, elasticsearch, lib, log, template, and txlog. The Derby DB files go under the db directory (similar to in OFBiz) and the same is true for the Elasticsearch files (if you are running an embedded ES node with local storage).

Some of these Moqui needs as separate folders, some can be combined with OFBiz ones, like the Derby and log dirs.

>> - 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
>
> Wait.  The webapp initializes the context factory?  There isn't a separate way to do this?  Does that mean Moqui is tied to a webapp? What kind of webapp?  I hope it isn't servlets.
>
> You mention it as weboot.  Does that mean it runs at the root of the webserver?  This might be a noob question.

Moqui is designed to facilitate deployment as a single WAR file. The Screen definitions in Moqui live in an hierarchy and you can add the root screen of each of your apps under the /apps screen, or under the root screen if you don’t want the /apps screen decorations. There are other ways to deploy it, like the static init approach mentioned below, but for most use this is by far the easiest. There is even support to add the runtime directory to the WAR file which gets picked up automatically when present, making it possible to throw the whole thing into one big WAR file and drop it into Tomcat or upload it to AWS ElasticBeanstalk or the myriad of similar hosting options.

>> - 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)
> Ah.  So that means that means that moqui-component needs a container definition.  Ignore the above then.
>
> I have never liked that ofbiz startup delays initialization of certain components until they are magically called from some random bit of java code, aka, the web container starting up.

Even though Moqui has a real init/destroy lifecycle, many things are lazy-loaded and cached just like in OFBiz. This provides a lot of flexibility in both development and for production maintenance/etc. Moqui does have some cache warming code for entities, services, and screens that is on by default in production mode.

>> - 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
>
> Sorry for the noob question, but does that mean that both ofbiz entityengine and moqui could talk to the same database backend(s), at the same time?

Yes. Initially this would be the easiest way to run them together. An early priority would be to use the Moqui transaction management (based on Bitronix or Atomikos, Bitronix being WAY faster and with the latest update far more reliable too) so that OFBiz Entity Engine and Moqui Entity Facade operations would share TX contexts.

>> 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.
>
> Actually, a bit simpler, would be to just see if moqui can be added to the classpath, and loaded, before translating any datamodels. Once that is done, then have a method that translates the model definitions dynamically at load time, so that they are always kept in sync.

Simpler at run time for sure, would take some work to build.

> Once this has proven, then that dynamic translation can be removed, and the output of it can become the new static definition of the model.
>
> The reason I suggest this way, is so that hot-deploy components(or other file modifications) that alter the entity definitions dynamically(extends-entity, whole new entity definitions) can also work transparently.

As you mentioned this would be a stop-gap effort until the Entity Engine is running through Moqui. If someone needs or wants to populate Moqui entity defs from OFBiz ones at runtime badly enough it can certainly be done, but not sure it HAS to be done. Moqui has the same concepts of entity extension, override, etc.

-David


Reply | Threaded
Open this post in threaded view
|

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

Hans Bakker
In reply to this post by David E. Jones-2
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 <[hidden email]> 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

123