VOTE: Begin Replacing OFBiz Framework With Moqui

[Jacques Le Roux]

Le 28/04/2015 16:42, Adam Heath a écrit :

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

hc.apache.org(HttpClient) was introduced with https://issues.apache.org/jira/browse/OFBIZ-3180. I also created
https://issues.apache.org/jira/browse/OFBIZ-4430
Never got a chance to seriously work on it

>
> The rest of the versioned jars are just as bad.

Which ones?

Jacques

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

[Jacques Le Roux]

I was rather reluctant about this but after the PoC concept has been introduced by several persons and reading  the last exchange between Adam and
David (where David said <<with the clarification that to me "begin replacing" implies a PoC effort in a branch>>) I sort of changed my mind, unlike
Nicolas I will not vote -1 but 0.

Like him I don't like the idea of plugging Moqui jars in OFBiz. On the other hand I understand Moqui is open source and everybody has access once a
Github account is created hence 0 and not -1. It's still not a +1 because this adds extra complexitiy (2 repos, 2 set of tools, how to communicate,
etc.) I don't like much :/

David mentioned  <<There is a chance Moqui Framework could become a separate ASF project, though the name "Apache Moqui" is oddly contradictory>>  I
guess still using Git as preferred commit medium (but as said Jacopo with anyway Svn as ultimate repo at the ASF). David also said he would prefer  
<<the distributed and moderated approaches used in the Linux kernel more than the community approach mandated by the ASF.>> which I believe was
David's main concern when he created Moqui.

That's could seem contradictory with ASF policy but remember that each project can define its own policy. Personnaly I don't see a problem with that,
I trust David not wanting to become a benevolent dictator, he many times always proved to simply want the best for the OFBiz project. Mixed with << I
would rather let people come along, express interest, and thoroughly prove merit before they take on such a role. >> I understand that a Moqui podling
would be created without direct connection with OFBiz committers.

It's certainly too early to get conclusions about having 2 separate projects working together (in ASF or not), but I can already see some concerns

If we introduce Moqui in OFBiz we can't avoid to speak about the 2 diverging ways of doing things at the UI level. Though I have not used Moqui I
believe it is more flexible for this aspect, but again this add complexity. I know we are speaking about that yet, just saying, because if the PoC
works it's the next step.

Sorry for the long and confusing post, it's hard to explain what I feel better.

Jacques


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

[Scott Gray-3]

-1

I think plenty of people are in favor of the concept (including me) but a
vote on replacing framework (and I assume eventually rewriting all of the
applications) is premature.  Has anyone looked into was is involved? With
the level of interest from the community I think a POC of some sort is the
best first step before we can hope to make an informed decision.

Regards
Scott
On 27 Apr 2015 02:45, "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
>

[Pierre Smits]

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

[Pierre Smits]

Apache LABS could be utilised for such. That way persons can work on it,
without hindrance of the projects by-laws and policies and without crowded
our repository with branches having a limited lifespan (such as PoCs
normally are intended). See http://labs.apache.org/

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 10:11 AM, Scott Gray <[hidden email]>
wrote:

> -1
>
> I think plenty of people are in favor of the concept (including me) but a
> vote on replacing framework (and I assume eventually rewriting all of the
> applications) is premature.  Has anyone looked into was is involved? With
> the level of interest from the community I think a POC of some sort is the
> best first step before we can hope to make an informed decision.
>
> Regards
> Scott
> On 27 Apr 2015 02:45, "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
> >
>

[Adam Heath-2]

On 04/29/2015 01:39 AM, Jacques Le Roux wrote:

> Le 28/04/2015 16:42, Adam Heath a écrit :
>>
>> 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.
>
> hc.apache.org(HttpClient) was introduced with
> https://issues.apache.org/jira/browse/OFBIZ-3180. I also created
> https://issues.apache.org/jira/browse/OFBIZ-4430
> Never got a chance to seriously work on it
>
>>
>> The rest of the versioned jars are just as bad.
>
> Which ones?
>
> Jacques
>

org.springframework seems to be at some 4.x version.  Ofbiz has 3.1.

birt is using date-based jars from 2010 and 2013.

ant is at 1.9.4, we have 1.9.0.

avalon-framework(4.2.0 in ofbiz) is no longer available.
avalon.apache.org is closed(!).

jdom in ofbiz is 1.1, but 2.0.6 is available.

junit is 4.10, but 4.12 is available.

resolver in base is 2.9.1, resolver in birt is 1.2.0(with a date), but
these may be different libs.

serializer is base is 2.9.1, serializer in birt is 2.7.1(with a date).

httpunit was last release in May 2008; xpp3 was last released in
November 2006.

I could go on.  This is based on reading the top-level pom.xml in
OFBIZ-6271, then doing some quick google searches and finding the
download pages.

There are also many jars that have no version at all in their name.

[Ron Wheeler]

What is the reason not to absorb Moqui or a fork of Moqui into OFBiz if
we decide to replace the existing framework with Moqui.

Is there a reason to have Moqui as a separate Apache project? Seems like
extra overhead for no advantage.

If Moqui is a separate deliverable of the OFBiz project and included in
the OFBiz ERP as a clean dependency, then managing Moqui development
with git, Maven and any other tool should not make the OFBiz universe
unstable even if the main development stays on SVN and Ant.

It should probably have its own release roadmap if it is used by other
projects but once again, I don't see any negative impact on the rest of
OFBiz.

I am not sure that it is a good idea in general but these issues are not
the source of any concern.

Ron



On 29/04/2015 3:41 AM, Jacques Le Roux wrote:

> I was rather reluctant about this but after the PoC concept has been
> introduced by several persons and reading  the last exchange between
> Adam and David (where David said <<with the clarification that to me
> "begin replacing" implies a PoC effort in a branch>>) I sort of
> changed my mind, unlike Nicolas I will not vote -1 but 0.
>
> Like him I don't like the idea of plugging Moqui jars in OFBiz. On the
> other hand I understand Moqui is open source and everybody has access
> once a Github account is created hence 0 and not -1. It's still not a
> +1 because this adds extra complexitiy (2 repos, 2 set of tools, how
> to communicate, etc.) I don't like much :/
>
> David mentioned  <<There is a chance Moqui Framework could become a
> separate ASF project, though the name "Apache Moqui" is oddly
> contradictory>>  I guess still using Git as preferred commit medium
> (but as said Jacopo with anyway Svn as ultimate repo at the ASF).
> David also said he would prefer  <<the distributed and moderated
> approaches used in the Linux kernel more than the community approach
> mandated by the ASF.>> which I believe was David's main concern when
> he created Moqui.
>
> That's could seem contradictory with ASF policy but remember that each
> project can define its own policy. Personnaly I don't see a problem
> with that, I trust David not wanting to become a benevolent dictator,
> he many times always proved to simply want the best for the OFBiz
> project. Mixed with << I would rather let people come along, express
> interest, and thoroughly prove merit before they take on such a role.
> >> I understand that a Moqui podling would be created without direct
> connection with OFBiz committers.
>
> It's certainly too early to get conclusions about having 2 separate
> projects working together (in ASF or not), but I can already see some
> concerns
>
> If we introduce Moqui in OFBiz we can't avoid to speak about the 2
> diverging ways of doing things at the UI level. Though I have not used
> Moqui I believe it is more flexible for this aspect, but again this
> add complexity. I know we are speaking about that yet, just saying,
> because if the PoC works it's the next step.
>
> Sorry for the long and confusing post, it's hard to explain what I
> feel better.
>
> Jacques
>
>
> 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.
>>
>

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

[Jacques Le Roux]

Le 29/04/2015 16:49, Adam Heath a écrit :

>
> On 04/29/2015 01:39 AM, Jacques Le Roux wrote:
>> Le 28/04/2015 16:42, Adam Heath a écrit :
>>>
>>> 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.
>>
>> hc.apache.org(HttpClient) was introduced with https://issues.apache.org/jira/browse/OFBIZ-3180. I also created
>> https://issues.apache.org/jira/browse/OFBIZ-4430
>> Never got a chance to seriously work on it
>>
>>>
>>> The rest of the versioned jars are just as bad.
>>
>> Which ones?
>>
>> Jacques
>>
>
> org.springframework seems to be at some 4.x version.  Ofbiz has 3.1.
>
> birt is using date-based jars from 2010 and 2013.

Yes: https://issues.apache.org/jira/browse/OFBIZ-5744

>
> ant is at 1.9.4, we have 1.9.0.
>
> avalon-framework(4.2.0 in ofbiz) is no longer available. avalon.apache.org is closed(!).

This was introduce with http://svn.apache.org/viewvc?view=revision&revision=746645 and is no longer used

>
> jdom in ofbiz is 1.1, but 2.0.6 is available.

Only JDOMException is used in images related classes

>
> junit is 4.10, but 4.12 is available.
>
> resolver in base is 2.9.1, resolver in birt is 1.2.0(with a date), but these may be different libs.
>
> serializer is base is 2.9.1, serializer in birt is 2.7.1(with a date).

Yes Birt needs to be updated, Chatree who is now a committer said he will take care of it when he will have finished his studies (Master)

>
> httpunit was last release in May 2008; xpp3 was last released in November 2006.
>
> I could go on.  This is based on reading the top-level pom.xml in OFBIZ-6271, then doing some quick google searches and finding the download pages.
>
> There are also many jars that have no version at all in their name.
>
>

Thanks, we should use to create Jiras, all of them...

Finally Maven proved to be useful :) But I remember some cases we needed to change our code because of changes in the libs. It was never hard stuff
but still we had to get our hand dirty.

Jacques
PS: this remembers we should certainly look at updating jQuery also

[Adam Heath-2]

On 04/29/2015 02:17 PM, Jacques Le Roux wrote:
> [snip]

> Finally Maven proved to be useful :)  [snip]

Everything always has at least one use; physical things can be paper
weights; virtual things can take up disk space.

jk

[Jacopo Cappellato-5]

On Apr 29, 2015, at 9:17 PM, Jacques Le Roux <[hidden email]> wrote:
>>
>> avalon-framework(4.2.0 in ofbiz) is no longer available. avalon.apache.org is closed(!).
>
> This was introduce with http://svn.apache.org/viewvc?view=revision&revision=746645 and is no longer used
>

Avalon is a dependency for FOP.

>>
>> jdom in ofbiz is 1.1, but 2.0.6 is available.
>
> Only JDOMException is used in images related classes
>

Several jars have dependencies on jdom: Freemarker, Rome, Ant Contrib, Xstreams

Jacopo

[David E. Jones-2]

> On 29 Apr 2015, at 00:41, Jacques Le Roux <[hidden email]> wrote:
>
> I was rather reluctant about this but after the PoC concept has been introduced by several persons and reading  the last exchange between Adam and David (where David said <<with the clarification that to me "begin replacing" implies a PoC effort in a branch>>) I sort of changed my mind, unlike Nicolas I will not vote -1 but 0.
>
> Like him I don't like the idea of plugging Moqui jars in OFBiz. On the other hand I understand Moqui is open source and everybody has access once a Github account is created hence 0 and not -1. It's still not a +1 because this adds extra complexitiy (2 repos, 2 set of tools, how to communicate, etc.) I don't like much :/

Moqui Framework IS a separate project, more or less like any other JAR or set of JARs included in OFBiz. It would always be maintained separately. If you think of using Moqui as adding another repo, that’s strange… like saying that OFBiz is currently split across dozens of repositories, one for each other open source project used in OFBiz.

Also keep in mind that there are other applications, both open source and commercial, based on Moqui. The ecosystem around Moqui and the applications around it are what have driven it to the point where it is now, and whether or not OFBiz uses Moqui all of that will continue.

> David mentioned  <<There is a chance Moqui Framework could become a separate ASF project, though the name "Apache Moqui" is oddly contradictory>>  I guess still using Git as preferred commit medium (but as said Jacopo with anyway Svn as ultimate repo at the ASF). David also said he would prefer  <<the distributed and moderated approaches used in the Linux kernel more than the community approach mandated by the ASF.>> which I believe was David's main concern when he created Moqui.
>
> That's could seem contradictory with ASF policy but remember that each project can define its own policy. Personnaly I don't see a problem with that, I trust David not wanting to become a benevolent dictator, he many times always proved to simply want the best for the OFBiz project. Mixed with << I would rather let people come along, express interest, and thoroughly prove merit before they take on such a role. >> I understand that a Moqui podling would be created without direct connection with OFBiz committers.
>
> It's certainly too early to get conclusions about having 2 separate projects working together (in ASF or not), but I can already see some concerns
>
> If we introduce Moqui in OFBiz we can't avoid to speak about the 2 diverging ways of doing things at the UI level. Though I have not used Moqui I believe it is more flexible for this aspect, but again this add complexity. I know we are speaking about that yet, just saying, because if the PoC works it's the next step.
>
> Sorry for the long and confusing post, it's hard to explain what I feel better.

This is the crux of the discussion for OFBiz: how much of the development approach driven by the framework do you want to change? Do you want to continue doing things the same way or look at alternative approaches that might be better (cleaner application artifacts, easier customization, better security, a wider variety of tools, more efficient development)?

You mentioned above the community structure as my main reason for creating Moqui… it is partly true in that it is the reason I chose to do it as a separate project and not an ASF project. However, the real reason was continuing to explore some of the principles that went into the design of the OFBiz Framework and taking them to the next level… including significant cleanups and modernization that the OFBiz Framework needs badly.

My list of desired changes to OFBiz (after nearly a decade) got more and more into things that would have required dramatic refactoring and breaking backwards compatibility in MAJOR ways. After trying a bit within OFBiz it became obvious that was impossible, and would have been extremely inefficient in terms of the time required. Doing it as a separate project solved that.

The real question behind this vote is: how do you want to do things in the future? If it is similar to how things are done in Moqui then it’s there for you to use. If you like the OFBiz framework tools as they are, then there’s no reason to even consider it.

-David

[David E. Jones-2]

> On 29 Apr 2015, at 08:01, Ron Wheeler <[hidden email]> wrote:
>
> What is the reason not to absorb Moqui or a fork of Moqui into OFBiz if we decide to replace the existing framework with Moqui.
>
> Is there a reason to have Moqui as a separate Apache project? Seems like extra overhead for no advantage.

Moqui is already a separate project. The OFBiz community could certainly create a fork of Moqui and change whatever is desired (though that shouldn’t be necessary), but Moqui Framework is already a separate project with its own ecosystem of business artifacts and applications. That won’t ever change, Moqui will always be a separate project.

-David

[Jacques Le Roux]

Thanks Jacopo,

I was too fast, Jars dependencies hell :/

Jacques

Le 30/04/2015 07:22, Jacopo Cappellato a écrit :

> On Apr 29, 2015, at 9:17 PM, Jacques Le Roux <[hidden email]> wrote:
>>> avalon-framework(4.2.0 in ofbiz) is no longer available. avalon.apache.org is closed(!).
>> This was introduce with http://svn.apache.org/viewvc?view=revision&revision=746645 and is no longer used
>>
> Avalon is a dependency for FOP.
>
>>> jdom in ofbiz is 1.1, but 2.0.6 is available.
>> Only JDOMException is used in images related classes
>>
> Several jars have dependencies on jdom: Freemarker, Rome, Ant Contrib, Xstreams
>
> Jacopo
>

[Jacopo Cappellato-5]

On Apr 29, 2015, at 5:01 PM, Ron Wheeler <[hidden email]> wrote:

> What is the reason not to absorb Moqui or a fork of Moqui into OFBiz if we decide to replace the existing framework with Moqui.

It could be done but with some concerns:
* incorporating an external codebase requires some paperwork, if not a formal incubation process
* forking Moqui may not be beneficial for the Moqui project that is growing and gaining momentum now; it could add confusion and over time incompatibilities between the forks
* for historical reasons it may not be a wise choice: within *this* community and with the same persons we have now, David was unable to convince people about his new ideas; these new ideas are now implemented in Moqui; do the OFBiz people clearly understand the differences now and recognize that David was right? or are we just trying to grab the Moqui code and change it in the way that some of us think is right? I would like to hear, form the core committers of OFBiz, more about what they know and think about Moqui, and what are their plans about the integration... we may discover that there is not a shared plan and everyone thinks differently

>
> Is there a reason to have Moqui as a separate Apache project? Seems like extra overhead for no advantage.

This approach would indeed solve most of the issues I mentioned above (about the fork) but we have to consider the following:
* the current OFBiz framework is a huge codebase that is an asset for the OFBiz project: as a community we have to protect this asset unless we are sure that an external solution (Moqui binaries) already provides what we need; but this is an important decision because after that OFBiz will depend on the Moqui community/project
* ideally, we should have more connections between Moqui and OFBiz communities, apart from David; in this way it will be easier to exchange requirements, plans etc... but I am not sure, again for historical reasons, how many of us would be a good fit for the Moqui community

The two options mentioned above are both viable but there are pros and cons that need to be carefully evaluated and understood by everyone in the community before taking a decision for the greater good of the project (OFBiz, but also Moqui).

Jacopo

[Jacopo Cappellato-5]

On Apr 28, 2015, at 10:39 AM, David E. Jones <[hidden email]> 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.
> ...
> I would be happy to participate in this effort... if nothing else should be an interesting technical diversion.
>
> -David

-1 to "Begin Replacing OFBiz Framework With Moqui": the decision is very important and cannot be done on such uncertain basis; an experimental branch/poc is required to better understand the best architecture (there are several options) and impact for the applications; after that a cleaner roadmap could be discussed and only at that point a vote could be called; the persons willing to work on this should be prepared to accept that the community may not decide to accept the switch because I doubt they will get a "pre-approval"

+1 to this proposal by David, especially if we will be inclined to listen to David's advices because he is the one who designed the architecture of OFBiz and created Moqui: David's  experience, knowledge and, more generally, skills will be invaluable in this process

Jacopo

[Jacques Le Roux]

Le 30/04/2015 07:42, David E. Jones a écrit :
>> On 29 Apr 2015, at 00:41, Jacques Le Roux<[hidden email]>  wrote:
>> >
>> >I was rather reluctant about this but after the PoC concept has been introduced by several persons and reading  the last exchange between Adam and David (where David said <<with the clarification that to me "begin replacing" implies a PoC effort in a branch>>) I sort of changed my mind, unlike Nicolas I will not vote -1 but 0.
>> >
>> >Like him I don't like the idea of plugging Moqui jars in OFBiz. On the other hand I understand Moqui is open source and everybody has access once a Github account is created hence 0 and not -1. It's still not a +1 because this adds extra complexitiy (2 repos, 2 set of tools, how to communicate, etc.) I don't like much :/
> Moqui Framework IS a separate project, more or less like any other JAR or set of JARs included in OFBiz. It would always be maintained separately. If you think of using Moqui as adding another repo, that’s strange… like saying that OFBiz is currently split across dozens of repositories, one for each other open source project used in OFBiz.

Obviously, as always, there will be bugs to fix and improvements to suggest so we will have to create pull request, that's what I meant. BTW how this
compares to our current OFBiz strategy with Jira and releases logs?

Jacques

[Jacques Le Roux]

I totally agree :)

Le 30/04/2015 08:13, Jacopo Cappellato a écrit :
> +1 to this proposal by David, especially if we will be inclined to listen to David's advices because he is the one who designed the architecture of OFBiz and created Moqui: David's  experience, knowledge and, more generally, skills will be invaluable in this process
>
> Jacopo
>

[Adrian Crum-3]

+0

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/26/2015 3:44 PM, 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.
>

[Adrian Crum-3]

Here is the tally of the votes. This was a challenge because many
replies included votes for other things, so this tally represents my
best effort at counting votes for the original subject.

PMC Members (Binding)
---------------------
+0 | 2  (Adam Heath, Jacques Le Roux)
+1 | 1  (David Jones)
-1 | 3  (Nicolas Malin, Scott Gray, Jacopo Cappellato)


Others (non-Binding)
--------------------
+0 | 1  (Adrian Crum)
-1 | 2  (Ron Wheeler, Martin Becker)

The vote failed to pass with 3 -1 votes and 1 +1 vote.

The replies included a discussion about creating a POC branch to explore
the subject further. That can be done without a vote, so I will consider
this vote closed.


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/26/2015 3:44 PM, 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.
>

[Jacques Le Roux]

Thanks for the initiative Adrian!

Jacques

Le 30/04/2015 09:55, Adrian Crum a écrit :

> Here is the tally of the votes. This was a challenge because many replies included votes for other things, so this tally represents my best effort
> at counting votes for the original subject.
>
> PMC Members (Binding)
> ---------------------
> +0 | 2  (Adam Heath, Jacques Le Roux)
> +1 | 1  (David Jones)
> -1 | 3  (Nicolas Malin, Scott Gray, Jacopo Cappellato)
>
>
> Others (non-Binding)
> --------------------
> +0 | 1  (Adrian Crum)
> -1 | 2  (Ron Wheeler, Martin Becker)
>
> The vote failed to pass with 3 -1 votes and 1 +1 vote.
>
> The replies included a discussion about creating a POC branch to explore the subject further. That can be done without a vote, so I will consider
> this vote closed.
>
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/26/2015 3:44 PM, 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.
>>
>