Discussion: Replace framework by Moqui.

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

Discussion: Replace framework by Moqui.

hans_bakker
Again, as discussed at the ApacheCon in Austin we should start setting
up a plan how to best move the ERP application to the Moqui framework.
Moqui should not be part of the Apache foundation however the ERP
application should remain there.

Not only will it improve development of the ERP system but also will
establish a clean separation between application and frameworks and
hopefully getting David Jones back into the project.

Yes, I realize i open the pandora box :-) but we need to make some major
decisions....

Regards,
Hans Bakker
antwebsystems.com


Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

Adrian Crum-3
Generally speaking, I am in favor of using another framework. I have two
reservations about Moqui:

1. It is controlled by a single person - so responsiveness to issues are
dependent on that person's availability.

2. It repeats a lot of mistakes that have been made in OFBiz, so those
things will need to be fixed again in Moqui after we bring it on board.

Neither one is a show-stopper for me.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/20/2015 6:31 AM, Hans Bakker wrote:

> Again, as discussed at the ApacheCon in Austin we should start setting
> up a plan how to best move the ERP application to the Moqui framework.
> Moqui should not be part of the Apache foundation however the ERP
> application should remain there.
>
> Not only will it improve development of the ERP system but also will
> establish a clean separation between application and frameworks and
> hopefully getting David Jones back into the project.
>
> Yes, I realize i open the pandora box :-) but we need to make some major
> decisions....
>
> Regards,
> Hans Bakker
> antwebsystems.com
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

Michael Brohl-3
In reply to this post by hans_bakker
Hi Hans, all,

interesting discussion!

Could you explain in more detail how the overall architecture of this
proposal would look like?
What will be Moqui/Moqui based and what will be left in OFBiz?

I would ask the question: what is OFBiz without it's framework and the ERP?

Thanks and regards,

Michael
ecomify.de

Am 20.04.15 um 07:31 schrieb Hans Bakker:

> Again, as discussed at the ApacheCon in Austin we should start setting
> up a plan how to best move the ERP application to the Moqui framework.
> Moqui should not be part of the Apache foundation however the ERP
> application should remain there.
>
> Not only will it improve development of the ERP system but also will
> establish a clean separation between application and frameworks and
> hopefully getting David Jones back into the project.
>
> Yes, I realize i open the pandora box :-) but we need to make some
> major decisions....
>
> Regards,
> Hans Bakker
> antwebsystems.com
>
>


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

Re: Discussion: Replace framework by Moqui.

Michael Brohl-3
In reply to this post by Adrian Crum-3
Hi Adrian,

I'm really interested in your and other community members' opinions
about the 2nd point.

I think it could help to set up some kind of matrix with the different
points and some proposals of how to solve them/ implement them in
another way.

Thanks and regards,

Michael
ecomify.de

Am 20.04.15 um 09:47 schrieb Adrian Crum:

> Generally speaking, I am in favor of using another framework. I have
> two reservations about Moqui:
>
> 1. It is controlled by a single person - so responsiveness to issues
> are dependent on that person's availability.
>
> 2. It repeats a lot of mistakes that have been made in OFBiz, so those
> things will need to be fixed again in Moqui after we bring it on board.
>
> Neither one is a show-stopper for me.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>


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

Re: Discussion: Replace framework by Moqui.

Adrian Crum-3
I agree a matrix would be nice to have, but most likely those issues
will be addressed as we try to integrate Moqui with the rest of the project.

Also, I performed my code analysis a year or two ago, so some of things
might have been fixed by now.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/20/2015 9:49 AM, Michael Brohl wrote:

> Hi Adrian,
>
> I'm really interested in your and other community members' opinions
> about the 2nd point.
>
> I think it could help to set up some kind of matrix with the different
> points and some proposals of how to solve them/ implement them in
> another way.
>
> Thanks and regards,
>
> Michael
> ecomify.de
>
> Am 20.04.15 um 09:47 schrieb Adrian Crum:
>> Generally speaking, I am in favor of using another framework. I have
>> two reservations about Moqui:
>>
>> 1. It is controlled by a single person - so responsiveness to issues
>> are dependent on that person's availability.
>>
>> 2. It repeats a lot of mistakes that have been made in OFBiz, so those
>> things will need to be fixed again in Moqui after we bring it on board.
>>
>> Neither one is a show-stopper for me.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

Pierre Smits
In reply to this post by hans_bakker
Quoting Hans: 'getting David Jones back into the project'

Was he out? I didn't notice.

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

Re: Discussion: Replace framework by Moqui.

Jacques Le Roux
Administrator
In reply to this post by Adrian Crum-3
Le 20/04/2015 09:47, Adrian Crum a écrit :
> Generally speaking, I am in favor of using another framework. I have two reservations about Moqui:
>
> 1. It is controlled by a single person - so responsiveness to issues are dependent on that person's availability.

This is indeed a regression from the current community sharing. On the other hand a such change would not be done in one day, so we would have a long
period to experiment in parallel before possibly switching to Moqui.
I also guess in such cases David could open the Moqui to people he trusts. I though wonder how this would be linked together. Nothing blocking but to
be seriously thought about, not only technically but legally. I know it's David's will to share and he proved it already with OFBiz but the licensing
aspect is not clear to me http://www.moqui.org/#model.

>
> 2. It repeats a lot of mistakes that have been made in OFBiz, so those things will need to be fixed again in Moqui after we bring it on board.

Indeed, a lot of fixes have been done recently in OFBiz which is battle tested for years. Moqui though certainly well done, is still young and we
would need to compare them, point by point.

>
> Neither one is a show-stopper for me.

Same here, just cautious.

Jacques

>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/20/2015 6:31 AM, Hans Bakker wrote:
>> Again, as discussed at the ApacheCon in Austin we should start setting
>> up a plan how to best move the ERP application to the Moqui framework.
>> Moqui should not be part of the Apache foundation however the ERP
>> application should remain there.
>>
>> Not only will it improve development of the ERP system but also will
>> establish a clean separation between application and frameworks and
>> hopefully getting David Jones back into the project.
>>
>> Yes, I realize i open the pandora box :-) but we need to make some major
>> decisions....
>>
>> Regards,
>> Hans Bakker
>> antwebsystems.com
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

Adrian Crum-3
Moqui is in the public domain. In other words, there is no license.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/20/2015 10:24 AM, Jacques Le Roux wrote:

> Le 20/04/2015 09:47, Adrian Crum a écrit :
>> Generally speaking, I am in favor of using another framework. I have
>> two reservations about Moqui:
>>
>> 1. It is controlled by a single person - so responsiveness to issues
>> are dependent on that person's availability.
>
> This is indeed a regression from the current community sharing. On the
> other hand a such change would not be done in one day, so we would have
> a long period to experiment in parallel before possibly switching to Moqui.
> I also guess in such cases David could open the Moqui to people he
> trusts. I though wonder how this would be linked together. Nothing
> blocking but to be seriously thought about, not only technically but
> legally. I know it's David's will to share and he proved it already with
> OFBiz but the licensing aspect is not clear to me
> http://www.moqui.org/#model.
>
>>
>> 2. It repeats a lot of mistakes that have been made in OFBiz, so those
>> things will need to be fixed again in Moqui after we bring it on board.
>
> Indeed, a lot of fixes have been done recently in OFBiz which is battle
> tested for years. Moqui though certainly well done, is still young and
> we would need to compare them, point by point.
>
>>
>> Neither one is a show-stopper for me.
>
> Same here, just cautious.
>
> Jacques
>
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/20/2015 6:31 AM, Hans Bakker wrote:
>>> Again, as discussed at the ApacheCon in Austin we should start setting
>>> up a plan how to best move the ERP application to the Moqui framework.
>>> Moqui should not be part of the Apache foundation however the ERP
>>> application should remain there.
>>>
>>> Not only will it improve development of the ERP system but also will
>>> establish a clean separation between application and frameworks and
>>> hopefully getting David Jones back into the project.
>>>
>>> Yes, I realize i open the pandora box :-) but we need to make some major
>>> decisions....
>>>
>>> Regards,
>>> Hans Bakker
>>> antwebsystems.com
>>>
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

David E. Jones-2
In reply to this post by Pierre Smits

I'll admit I got a chuckle out of this one. Yes, my activity in OFBiz dropped to pretty close to zero in 2010 after I started Moqui/Mantle/etc. I think that was before you got more closely involved Pierre.

OpenHub keeps a good history of this, for commits anyway, though note that for OFBiz the history for mid-2003 to early 2006 was lost with the demise of the OFBiz project on java.net (where we were before the ASF):

https://www.openhub.net/accounts/jonesde/positions

I'll reply to other messages with more thoughts on Moqui in OFBiz.

-David


> On 20 Apr 2015, at 02:11, Pierre Smits <[hidden email]> wrote:
>
> Quoting Hans: 'getting David Jones back into the project'
>
> Was he out? I didn't notice.
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

Pierre Smits
I chuckled too.

Op maandag 20 april 2015 heeft David E. Jones <[hidden email]> het volgende
geschreven:

>
> I'll admit I got a chuckle out of this one. Yes, my activity in OFBiz
> dropped to pretty close to zero in 2010 after I started Moqui/Mantle/etc. I
> think that was before you got more closely involved Pierre.
>
> OpenHub keeps a good history of this, for commits anyway, though note that
> for OFBiz the history for mid-2003 to early 2006 was lost with the demise
> of the OFBiz project on java.net (where we were before the ASF):
>
> https://www.openhub.net/accounts/jonesde/positions
>
> I'll reply to other messages with more thoughts on Moqui in OFBiz.
>
> -David
>
>
> > On 20 Apr 2015, at 02:11, Pierre Smits <[hidden email]
> <javascript:;>> wrote:
> >
> > Quoting Hans: 'getting David Jones back into the project'
> >
> > Was he out? I didn't notice.
> >
> > 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
>
>

--
Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

Jacques Le Roux
Administrator
In reply to this post by Jacques Le Roux
Something I missed to mention because it's obvious (the elephant in the room). I'm notably cautious because I don't know Moqui but its architecture.
So I can't imagine what moving to Moqui would mean for existing projects.
Maybe it's not that complicated and tools could be provided? It's an important point to consider for our existing users...

Jacques

Le 20/04/2015 11:24, Jacques Le Roux a écrit :

> Le 20/04/2015 09:47, Adrian Crum a écrit :
>> Generally speaking, I am in favor of using another framework. I have two reservations about Moqui:
>>
>> 1. It is controlled by a single person - so responsiveness to issues are dependent on that person's availability.
>
> This is indeed a regression from the current community sharing. On the other hand a such change would not be done in one day, so we would have a
> long period to experiment in parallel before possibly switching to Moqui.
> I also guess in such cases David could open the Moqui to people he trusts. I though wonder how this would be linked together. Nothing blocking but
> to be seriously thought about, not only technically but legally. I know it's David's will to share and he proved it already with OFBiz but the
> licensing aspect is not clear to me http://www.moqui.org/#model.
>
>>
>> 2. It repeats a lot of mistakes that have been made in OFBiz, so those things will need to be fixed again in Moqui after we bring it on board.
>
> Indeed, a lot of fixes have been done recently in OFBiz which is battle tested for years. Moqui though certainly well done, is still young and we
> would need to compare them, point by point.
>
>>
>> Neither one is a show-stopper for me.
>
> Same here, just cautious.
>
> Jacques
>
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/20/2015 6:31 AM, Hans Bakker wrote:
>>> Again, as discussed at the ApacheCon in Austin we should start setting
>>> up a plan how to best move the ERP application to the Moqui framework.
>>> Moqui should not be part of the Apache foundation however the ERP
>>> application should remain there.
>>>
>>> Not only will it improve development of the ERP system but also will
>>> establish a clean separation between application and frameworks and
>>> hopefully getting David Jones back into the project.
>>>
>>> Yes, I realize i open the pandora box :-) but we need to make some major
>>> decisions....
>>>
>>> Regards,
>>> Hans Bakker
>>> antwebsystems.com
>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

David E. Jones-2
In reply to this post by Jacques Le Roux

> On 20 Apr 2015, at 02:24, Jacques Le Roux <[hidden email]> wrote:
>
> Le 20/04/2015 09:47, Adrian Crum a écrit :
>> Generally speaking, I am in favor of using another framework. I have two reservations about Moqui:
>>
>> 1. It is controlled by a single person - so responsiveness to issues are dependent on that person's availability.
>
> This is indeed a regression from the current community sharing. On the other hand a such change would not be done in one day, so we would have a long period to experiment in parallel before possibly switching to Moqui.
> I also guess in such cases David could open the Moqui to people he trusts. I though wonder how this would be linked together. Nothing blocking but to be seriously thought about, not only technically but legally. I know it's David's will to share and he proved it already with OFBiz but the licensing aspect is not clear to me http://www.moqui.org/#model.

With Moqui it's no secret that I chose the "code over community" route which is certainly different from the ASF emphasis on community (and my emphasis on community and collaboration from the beginning in OFBiz).

Moqui Framework is now pretty mature and I have sent out a couple of solicitations (in the LinkedIn group) for more contributors, but I'm in no hurry to bring on other committers/moderators... better to wait until clearly interested and capable people come along. The infrastructure is in place for this on GitHub, ie the main repo is under the "moqui" group and not my personal account any more so it is easy to add others to that group with permission for particular repositories (ie moqui vs mantle, HiveMind, etc).

Part of the reason I'm less worried about this is the different model for source management that Git makes possible and GitHub makes easy. In other words, the magic of distributed source management. Distributed source management and the moderator model make it possible for "forks" to exist that have variations on the main code base that are available for all and pulled into the main code base by moderators. You don't have to be a moderator to contribute, or even share your code with the world.

The whole distributed source and moderator model is very different from the community model in OFBiz, and overall better for some things and worse for others. Many big projects use this model, including the Linux kernel which is probably the biggest and the use of this model for the Linux kernel is exactly where git came from.

My guess is that if OFBiz started using Moqui Framework one or more current OFBiz committers would become moderators with commit access to the main Moqui Framework repository.

>> 2. It repeats a lot of mistakes that have been made in OFBiz, so those things will need to be fixed again in Moqui after we bring it on board.
>
> Indeed, a lot of fixes have been done recently in OFBiz which is battle tested for years. Moqui though certainly well done, is still young and we would need to compare them, point by point.

I'd love to hear more detail on this. I know one criticism in the past from Adrian is Moqui's approach to object type conversions, especially in the Entity Facade (the part of Moqui similar to the OFBiz Entity Engine). In some parts of Moqui, like for service parameters, it uses the Groovy type conversion which is pretty good but isn't a pluggable type conversion framework as I'm sure Adrian would like to see... but that honestly I still have yet to find a need for.

On the entity level I prefer the current approach, mostly for performance reasons. In recent changes to the framework for performance improvements (which were significant... Moqui now getting around 15,000 entity ops per second as opposed to 3,000 before the latest changes, and close to 300 in the original version of Moqui though that was on an older laptop/etc and before ANY optimizations where done). This does limit the types available for entity fields, but is that really an issue? You're going to a database through JDBC, and really just the least common denominator of types available in databases to cleanly run on various ones, so there aren't many options in the first place! We can take advantage of that for simpler code and better performance.

>> Neither one is a show-stopper for me.
>
> Same here, just cautious.

Caution is good in this case... to be honest I'm not sure using Moqui Framework in OFBiz is a good idea (as I've mentioned before), will write more on that in another reply.

-David


Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

Ron Wheeler
Would Moqui become a sub-project of OFBiz with distinct deliverable with
an Apache license?
Or is that too much community?

Ron


On 20/04/2015 1:19 PM, David E. Jones wrote:

>> On 20 Apr 2015, at 02:24, Jacques Le Roux <[hidden email]> wrote:
>>
>> Le 20/04/2015 09:47, Adrian Crum a écrit :
>>> Generally speaking, I am in favor of using another framework. I have two reservations about Moqui:
>>>
>>> 1. It is controlled by a single person - so responsiveness to issues are dependent on that person's availability.
>> This is indeed a regression from the current community sharing. On the other hand a such change would not be done in one day, so we would have a long period to experiment in parallel before possibly switching to Moqui.
>> I also guess in such cases David could open the Moqui to people he trusts. I though wonder how this would be linked together. Nothing blocking but to be seriously thought about, not only technically but legally. I know it's David's will to share and he proved it already with OFBiz but the licensing aspect is not clear to me http://www.moqui.org/#model.
> With Moqui it's no secret that I chose the "code over community" route which is certainly different from the ASF emphasis on community (and my emphasis on community and collaboration from the beginning in OFBiz).
>
> Moqui Framework is now pretty mature and I have sent out a couple of solicitations (in the LinkedIn group) for more contributors, but I'm in no hurry to bring on other committers/moderators... better to wait until clearly interested and capable people come along. The infrastructure is in place for this on GitHub, ie the main repo is under the "moqui" group and not my personal account any more so it is easy to add others to that group with permission for particular repositories (ie moqui vs mantle, HiveMind, etc).
>
> Part of the reason I'm less worried about this is the different model for source management that Git makes possible and GitHub makes easy. In other words, the magic of distributed source management. Distributed source management and the moderator model make it possible for "forks" to exist that have variations on the main code base that are available for all and pulled into the main code base by moderators. You don't have to be a moderator to contribute, or even share your code with the world.
>
> The whole distributed source and moderator model is very different from the community model in OFBiz, and overall better for some things and worse for others. Many big projects use this model, including the Linux kernel which is probably the biggest and the use of this model for the Linux kernel is exactly where git came from.
>
> My guess is that if OFBiz started using Moqui Framework one or more current OFBiz committers would become moderators with commit access to the main Moqui Framework repository.
>
>>> 2. It repeats a lot of mistakes that have been made in OFBiz, so those things will need to be fixed again in Moqui after we bring it on board.
>> Indeed, a lot of fixes have been done recently in OFBiz which is battle tested for years. Moqui though certainly well done, is still young and we would need to compare them, point by point.
> I'd love to hear more detail on this. I know one criticism in the past from Adrian is Moqui's approach to object type conversions, especially in the Entity Facade (the part of Moqui similar to the OFBiz Entity Engine). In some parts of Moqui, like for service parameters, it uses the Groovy type conversion which is pretty good but isn't a pluggable type conversion framework as I'm sure Adrian would like to see... but that honestly I still have yet to find a need for.
>
> On the entity level I prefer the current approach, mostly for performance reasons. In recent changes to the framework for performance improvements (which were significant... Moqui now getting around 15,000 entity ops per second as opposed to 3,000 before the latest changes, and close to 300 in the original version of Moqui though that was on an older laptop/etc and before ANY optimizations where done). This does limit the types available for entity fields, but is that really an issue? You're going to a database through JDBC, and really just the least common denominator of types available in databases to cleanly run on various ones, so there aren't many options in the first place! We can take advantage of that for simpler code and better performance.
>
>>> Neither one is a show-stopper for me.
>> Same here, just cautious.
> Caution is good in this case... to be honest I'm not sure using Moqui Framework in OFBiz is a good idea (as I've mentioned before), will write more on that in another reply.
>
> -David
>
>
>


--
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: Discussion: Replace framework by Moqui.

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

> On 19 Apr 2015, at 22:31, Hans Bakker <[hidden email]> wrote:
>
> Again, as discussed at the ApacheCon in Austin we should start setting up a plan how to best move the ERP application to the Moqui framework. Moqui should not be part of the Apache foundation however the ERP application should remain there.
>
> Not only will it improve development of the ERP system but also will establish a clean separation between application and frameworks and hopefully getting David Jones back into the project.
>
> Yes, I realize i open the pandora box :-) but we need to make some major decisions....

I'll write this general reply with my OFBiz hat on, not my Moqui one. For Moqui Framework being used by OFBiz would be fantastic. It would bring a lot of well needed use and attention to the project and get it to a level that would take much longer with the current pace of growth. The growth is increasing, but it's nothing like the early years of OFBiz when the marketplace was so different... at that time OFBiz was unique as there weren't many feature-rich open source ecommerce or ERP systems, especially not in Java! I still find it amazing that OFBiz took off as much as it did... I was 23 years old when I started it, and only had 2 years of full-time development work behind me, and only 1 year of that was on ecommerce and ERP systems. Andrew had more experience with custom ecommerce development, but mostly in Perl IIRC.

Anyway, enough nostalgia, back to the present.

Using Moqui Framework in OFBiz would involve some really significant changes. The Moqui API is much cleaner (and everything is available through the single ExecutionContext class), but much different from the scattered static classes of the OFBiz framework. It may be possible to refactor much of the code with some regex search/replace wizardry, but there is a LOT of code in OFBiz to change.

The data model and to some extent service definitions would be easy. I have some FTL templates for transforming those that I'd be happy to share (they are in a private repo right now). I used these to create the little Moqui component that has the OFBiz data model from version 10.04 which I used with a client to run a sort of OFBiz/Moqui hybrid. On that note... if anyone wants to experiment with this that might be a good place to start: get the latest data model definitions in a Moqui component, deploy the Moqui WAR in the same servlet container as OFBiz (just drop it in an OFBiz component) and then run them in parallel accessing the same DB and play with migrating a few screens/etc.

IMO the biggest questions/concerns should be:

1. the significant effort required to do the migration
2. the impact on current users and applications

OFBiz would end up as a very different beast after such changes, there is no way around it. For example screen hierarchies, nesting, and URLs are handled totally different in Moqui. There are some very cool newer open source tools used in Moqui, and some cool features in Moqui that don't (yet) exist in OFBiz, and many of the more advanced and recent ones aren't mentioned here, but this is a basic list of fundamental differences between the two frameworks (see the "OFBiz: How does it compare to Moqui?" section near the bottom):

http://www.moqui.org/framework/index.html

OFBiz could do a custom set of FTL macros to transform screens and forms into HMTL/etc, but OOTB the UI is very different. This isn't just look and feel but also the approach to UI design. For example there are no lookup windows, other widgets and approaches are used instead (though those could be added... I just haven't found the need compared with other approaches that are often cleaner and easier for users). Looking at the demo server you'll see the big differences pretty quickly:

http://demo.moqui.org/

To go a deeper the Moqui book covers most of the framework and is available here:

http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf

Is it a good idea? I'm not sure about that. Both concerns 1 and 2 above are a big deal. It would be a huge change for OFBiz users and not in any way backwards compatible. Not only the code in OFBiz but also all custom code built on OFBiz would have to be changed to update to the newest versions. Given the community and user driven reality of OFBiz, my guess is that the current architecture would never be fully abandoned and would live on into the foreseeable future with both bug fixes and new features going into it.

On the other hand the growth potential is pretty substantial. Code in OFBiz would end up being much cleaner and smaller. Security (especially authz) could be ripped out of thousands of places and put in simple database configuration. There would be better ability to handle custom and generic RESTful and other web services. Elasticsearch is there ready to use for both full text search and analytics (ie using Elasticsearch as a distributed and efficient OLAP data store... with ETL done through simple mapping configuration as opposed to custom code). New developers would be able to get started much faster and work more efficiently, and experienced developers would be able to build custom apps faster than they've ever experienced. With Moqui and Mantle already to a pretty good place last fall I was able to build a 400 form ERP application in about 4 months working full time, and now Moqui/Mantle are far better because of this and other efforts going on so the time would be even less.

To muddy the waters more: the data model, logic, and UI in OFBiz have a lot of room for improvement. I made dozens of general changes, resulting in hundreds of physical changes, to the OFBiz data model when rewriting it for the Mantle Business Artifacts project. Most, but not all, of the general changes are listed here:

https://github.com/moqui/mantle/blob/master/mantle-udm/Planning.txt

On top of that there is the logic layer. Mantle has a 100% service logic layer unlike the object/service hybrid in OFBiz. There is a LOT of functionality for order processing in OFBiz, including a few features still not implemented in Mantle (though Mantle does have a few that aren't in OFBiz), but that part of OFBiz is one of the most difficult and error-prone parts to work on or customize. I've been on various contracts where they gave up making changes there so wanted to hire it out... and I've turned down a few because I hate working on it too! The Mantle approach gets rid of the whole ShoppingCart object idea (and the various related objects and services to get it to do general stuff) and just puts the cart in the database as a tentative order. This eliminates the need for many thousands of lines of code, and makes it more flexible and faster at the same time.

This is where I question whether it is a good idea to just replace the framework and leave all else as-is in OFBiz. I know very well that bringing this up is likely to stall the discussion and reduce the chances of OFBiz ever using Moqui, and the great thing for Moqui and OFBiz that it could be. Still, the effort required to do that migration is significant and IMO it would be far less effort to start with Moqui and Mantle and basically rewrite OFBiz to be a comprehensive business automation application suite, just as it is now, but cleaned up and streamlined for both developers and end-users in ways that are only dreamed of for OFBiz right now.

How long would that take? Depending on how many people are interested and get involved and how quickly they come up to speed on Moqui and Mantle (the book linked to above can help a lot with this, it covers the basics of Mantle too), my guess is that it could be to an alpha state and do everything OFBiz currently does and more (on the app level at least) within 6 months. IMO the result would be enough to compete well with projects like Odoo that are currently leapfrogging OFBiz... but are a serious pain to customize compared to OFBiz, and every single one has more restrictive licensing and are corporate backed as opposed to community driven.

This could be shorted with a starting point for the applications, and if there was enough interest theres a chance that I could release the more generic parts of this Moqui-based ERP system that I'm working on. I've already gone through the effort of splitting out the generic screens into an application that runs on its own, and the industry specific ERP that I'm working on simply extends it with additional forms, screens, services, and a few entities (really not bad for an industry where generic ERP systems have totally failed to the very different practices and business processes common in the industry, so nearly all market share is in industry specific systems).

I know that's more than 2 cents of thoughts, even if it may only be worth that. ;) For those who have been around a while you know this sort of LONG email is consistent with my oft lamented style... hopefully it will that will at least bring a few chuckles and maybe some eye-rolling in fond remembrance of novel length mailing list threads.

-David


Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

David E. Jones-2
In reply to this post by Ron Wheeler

> On 20 Apr 2015, at 11:35, Ron Wheeler <[hidden email]> wrote:
>
> Would Moqui become a sub-project of OFBiz with distinct deliverable with an Apache license?
> Or is that too much community?

IMO they are better as distinct projects. There is a chance Moqui Framework could become a separate ASF project, though the name "Apache Moqui" is oddly contradictory (I chose the name based on Moqui Marbles, but it is also another name for the Hopi tribe). More seriously, these days I like the distributed and moderated approaches used in the Linux kernel more than the community approach mandated by the ASF.

As for community, regardless of the structure the various Moqui projects are now in a good place for a bigger community and it is needed for more significant growth in the projects. There are parallels to OFBiz which was mostly two people until around 2004-2005 when the project exploded (we had other contributors before then, but most not so involved or enduring). Jacopo was the first really strong contributor in 2003, and remains to this day! I'm still looking for a "Jacopo" for Moqui... heck, maybe it'll be Jacopo. ;) (No pressure Jacopo: I know you're a busy man and doing fantastic and important work elsewhere including OFBiz, Hotwax, and other projects you contribute to.)

As for licensing: the public domain "license" is even less restrictive than the Apache 2 license. The one thing that bothers me about the licensing approach, that I'll freely admit but that I'm not sure how to handle better, is the explicit patent grant that is in the Apache 2 license (which made it incompatible with GPL2, though GPL3 has it too so it is "compatible", ie no additional restrictions). In theory this shouldn't be a legal issue because releasing it as public domain means giving up most IP rights, and there is the prior art aspect of it too, but patent courts these days (at least in the USA) are awful and they don't seem to care about prior art unless you pay a few million USD to lawyers along with substantial court fees to get that recognized. In theory it shouldn't be an issue, not sure if it ever has been even for Apache 2 licensed code, but it could be and in theory the terms in the Apache 2 license make it cheaper to defend against patent claims (again in theory... chances are there would still be significant, possibly bankrupting, legal fees to defend against such).

-David


>
> On 20/04/2015 1:19 PM, David E. Jones wrote:
>>> On 20 Apr 2015, at 02:24, Jacques Le Roux <[hidden email]> wrote:
>>>
>>> Le 20/04/2015 09:47, Adrian Crum a écrit :
>>>> Generally speaking, I am in favor of using another framework. I have two reservations about Moqui:
>>>>
>>>> 1. It is controlled by a single person - so responsiveness to issues are dependent on that person's availability.
>>> This is indeed a regression from the current community sharing. On the other hand a such change would not be done in one day, so we would have a long period to experiment in parallel before possibly switching to Moqui.
>>> I also guess in such cases David could open the Moqui to people he trusts. I though wonder how this would be linked together. Nothing blocking but to be seriously thought about, not only technically but legally. I know it's David's will to share and he proved it already with OFBiz but the licensing aspect is not clear to me http://www.moqui.org/#model.
>> With Moqui it's no secret that I chose the "code over community" route which is certainly different from the ASF emphasis on community (and my emphasis on community and collaboration from the beginning in OFBiz).
>>
>> Moqui Framework is now pretty mature and I have sent out a couple of solicitations (in the LinkedIn group) for more contributors, but I'm in no hurry to bring on other committers/moderators... better to wait until clearly interested and capable people come along. The infrastructure is in place for this on GitHub, ie the main repo is under the "moqui" group and not my personal account any more so it is easy to add others to that group with permission for particular repositories (ie moqui vs mantle, HiveMind, etc).
>>
>> Part of the reason I'm less worried about this is the different model for source management that Git makes possible and GitHub makes easy. In other words, the magic of distributed source management. Distributed source management and the moderator model make it possible for "forks" to exist that have variations on the main code base that are available for all and pulled into the main code base by moderators. You don't have to be a moderator to contribute, or even share your code with the world.
>>
>> The whole distributed source and moderator model is very different from the community model in OFBiz, and overall better for some things and worse for others. Many big projects use this model, including the Linux kernel which is probably the biggest and the use of this model for the Linux kernel is exactly where git came from.
>>
>> My guess is that if OFBiz started using Moqui Framework one or more current OFBiz committers would become moderators with commit access to the main Moqui Framework repository.
>>
>>>> 2. It repeats a lot of mistakes that have been made in OFBiz, so those things will need to be fixed again in Moqui after we bring it on board.
>>> Indeed, a lot of fixes have been done recently in OFBiz which is battle tested for years. Moqui though certainly well done, is still young and we would need to compare them, point by point.
>> I'd love to hear more detail on this. I know one criticism in the past from Adrian is Moqui's approach to object type conversions, especially in the Entity Facade (the part of Moqui similar to the OFBiz Entity Engine). In some parts of Moqui, like for service parameters, it uses the Groovy type conversion which is pretty good but isn't a pluggable type conversion framework as I'm sure Adrian would like to see... but that honestly I still have yet to find a need for.
>>
>> On the entity level I prefer the current approach, mostly for performance reasons. In recent changes to the framework for performance improvements (which were significant... Moqui now getting around 15,000 entity ops per second as opposed to 3,000 before the latest changes, and close to 300 in the original version of Moqui though that was on an older laptop/etc and before ANY optimizations where done). This does limit the types available for entity fields, but is that really an issue? You're going to a database through JDBC, and really just the least common denominator of types available in databases to cleanly run on various ones, so there aren't many options in the first place! We can take advantage of that for simpler code and better performance.
>>
>>>> Neither one is a show-stopper for me.
>>> Same here, just cautious.
>> Caution is good in this case... to be honest I'm not sure using Moqui Framework in OFBiz is a good idea (as I've mentioned before), will write more on that in another reply.
>>
>> -David
>>
>>
>>
>
>
> --
> 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: Discussion: Replace framework by Moqui.

Pierre Smits
In reply to this post by David E. Jones-2
I can relate to a lot David has written. I have my share of experiences
with Moqui.

We have to be aware that every project (proprietary or Open Source)
somewhere in the lifespan faces the moment of breaking backwards
compatibility of their products. Even today there are still some products
whose owners had to walk that walk and survived.... But that is more about
the trustworthiness of the owner/project. And even then it were  hard
walks....

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 Mon, Apr 20, 2015 at 8:39 PM, David E. Jones <[hidden email]> wrote:

>
> > On 19 Apr 2015, at 22:31, Hans Bakker <[hidden email]>
> wrote:
> >
> > Again, as discussed at the ApacheCon in Austin we should start setting
> up a plan how to best move the ERP application to the Moqui framework.
> Moqui should not be part of the Apache foundation however the ERP
> application should remain there.
> >
> > Not only will it improve development of the ERP system but also will
> establish a clean separation between application and frameworks and
> hopefully getting David Jones back into the project.
> >
> > Yes, I realize i open the pandora box :-) but we need to make some major
> decisions....
>
> I'll write this general reply with my OFBiz hat on, not my Moqui one. For
> Moqui Framework being used by OFBiz would be fantastic. It would bring a
> lot of well needed use and attention to the project and get it to a level
> that would take much longer with the current pace of growth. The growth is
> increasing, but it's nothing like the early years of OFBiz when the
> marketplace was so different... at that time OFBiz was unique as there
> weren't many feature-rich open source ecommerce or ERP systems, especially
> not in Java! I still find it amazing that OFBiz took off as much as it
> did... I was 23 years old when I started it, and only had 2 years of
> full-time development work behind me, and only 1 year of that was on
> ecommerce and ERP systems. Andrew had more experience with custom ecommerce
> development, but mostly in Perl IIRC.
>
> Anyway, enough nostalgia, back to the present.
>
> Using Moqui Framework in OFBiz would involve some really significant
> changes. The Moqui API is much cleaner (and everything is available through
> the single ExecutionContext class), but much different from the scattered
> static classes of the OFBiz framework. It may be possible to refactor much
> of the code with some regex search/replace wizardry, but there is a LOT of
> code in OFBiz to change.
>
> The data model and to some extent service definitions would be easy. I
> have some FTL templates for transforming those that I'd be happy to share
> (they are in a private repo right now). I used these to create the little
> Moqui component that has the OFBiz data model from version 10.04 which I
> used with a client to run a sort of OFBiz/Moqui hybrid. On that note... if
> anyone wants to experiment with this that might be a good place to start:
> get the latest data model definitions in a Moqui component, deploy the
> Moqui WAR in the same servlet container as OFBiz (just drop it in an OFBiz
> component) and then run them in parallel accessing the same DB and play
> with migrating a few screens/etc.
>
> IMO the biggest questions/concerns should be:
>
> 1. the significant effort required to do the migration
> 2. the impact on current users and applications
>
> OFBiz would end up as a very different beast after such changes, there is
> no way around it. For example screen hierarchies, nesting, and URLs are
> handled totally different in Moqui. There are some very cool newer open
> source tools used in Moqui, and some cool features in Moqui that don't
> (yet) exist in OFBiz, and many of the more advanced and recent ones aren't
> mentioned here, but this is a basic list of fundamental differences between
> the two frameworks (see the "OFBiz: How does it compare to Moqui?" section
> near the bottom):
>
> http://www.moqui.org/framework/index.html
>
> OFBiz could do a custom set of FTL macros to transform screens and forms
> into HMTL/etc, but OOTB the UI is very different. This isn't just look and
> feel but also the approach to UI design. For example there are no lookup
> windows, other widgets and approaches are used instead (though those could
> be added... I just haven't found the need compared with other approaches
> that are often cleaner and easier for users). Looking at the demo server
> you'll see the big differences pretty quickly:
>
> http://demo.moqui.org/
>
> To go a deeper the Moqui book covers most of the framework and is
> available here:
>
> http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf
>
> Is it a good idea? I'm not sure about that. Both concerns 1 and 2 above
> are a big deal. It would be a huge change for OFBiz users and not in any
> way backwards compatible. Not only the code in OFBiz but also all custom
> code built on OFBiz would have to be changed to update to the newest
> versions. Given the community and user driven reality of OFBiz, my guess is
> that the current architecture would never be fully abandoned and would live
> on into the foreseeable future with both bug fixes and new features going
> into it.
>
> On the other hand the growth potential is pretty substantial. Code in
> OFBiz would end up being much cleaner and smaller. Security (especially
> authz) could be ripped out of thousands of places and put in simple
> database configuration. There would be better ability to handle custom and
> generic RESTful and other web services. Elasticsearch is there ready to use
> for both full text search and analytics (ie using Elasticsearch as a
> distributed and efficient OLAP data store... with ETL done through simple
> mapping configuration as opposed to custom code). New developers would be
> able to get started much faster and work more efficiently, and experienced
> developers would be able to build custom apps faster than they've ever
> experienced. With Moqui and Mantle already to a pretty good place last fall
> I was able to build a 400 form ERP application in about 4 months working
> full time, and now Moqui/Mantle are far better because of this and other
> efforts going on so the time would be even less.
>
> To muddy the waters more: the data model, logic, and UI in OFBiz have a
> lot of room for improvement. I made dozens of general changes, resulting in
> hundreds of physical changes, to the OFBiz data model when rewriting it for
> the Mantle Business Artifacts project. Most, but not all, of the general
> changes are listed here:
>
> https://github.com/moqui/mantle/blob/master/mantle-udm/Planning.txt
>
> On top of that there is the logic layer. Mantle has a 100% service logic
> layer unlike the object/service hybrid in OFBiz. There is a LOT of
> functionality for order processing in OFBiz, including a few features still
> not implemented in Mantle (though Mantle does have a few that aren't in
> OFBiz), but that part of OFBiz is one of the most difficult and error-prone
> parts to work on or customize. I've been on various contracts where they
> gave up making changes there so wanted to hire it out... and I've turned
> down a few because I hate working on it too! The Mantle approach gets rid
> of the whole ShoppingCart object idea (and the various related objects and
> services to get it to do general stuff) and just puts the cart in the
> database as a tentative order. This eliminates the need for many thousands
> of lines of code, and makes it more flexible and faster at the same time.
>
> This is where I question whether it is a good idea to just replace the
> framework and leave all else as-is in OFBiz. I know very well that bringing
> this up is likely to stall the discussion and reduce the chances of OFBiz
> ever using Moqui, and the great thing for Moqui and OFBiz that it could be.
> Still, the effort required to do that migration is significant and IMO it
> would be far less effort to start with Moqui and Mantle and basically
> rewrite OFBiz to be a comprehensive business automation application suite,
> just as it is now, but cleaned up and streamlined for both developers and
> end-users in ways that are only dreamed of for OFBiz right now.
>
> How long would that take? Depending on how many people are interested and
> get involved and how quickly they come up to speed on Moqui and Mantle (the
> book linked to above can help a lot with this, it covers the basics of
> Mantle too), my guess is that it could be to an alpha state and do
> everything OFBiz currently does and more (on the app level at least) within
> 6 months. IMO the result would be enough to compete well with projects like
> Odoo that are currently leapfrogging OFBiz... but are a serious pain to
> customize compared to OFBiz, and every single one has more restrictive
> licensing and are corporate backed as opposed to community driven.
>
> This could be shorted with a starting point for the applications, and if
> there was enough interest theres a chance that I could release the more
> generic parts of this Moqui-based ERP system that I'm working on. I've
> already gone through the effort of splitting out the generic screens into
> an application that runs on its own, and the industry specific ERP that I'm
> working on simply extends it with additional forms, screens, services, and
> a few entities (really not bad for an industry where generic ERP systems
> have totally failed to the very different practices and business processes
> common in the industry, so nearly all market share is in industry specific
> systems).
>
> I know that's more than 2 cents of thoughts, even if it may only be worth
> that. ;) For those who have been around a while you know this sort of LONG
> email is consistent with my oft lamented style... hopefully it will that
> will at least bring a few chuckles and maybe some eye-rolling in fond
> remembrance of novel length mailing list threads.
>
> -David
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

Jacques Le Roux
Administrator
In reply to this post by David E. Jones-2
Long story short, I'd rather go the complete Moqui way :) But I'm not there yet, not so far though...

Jacques

Le 20/04/2015 20:39, David E. Jones a écrit :

>> On 19 Apr 2015, at 22:31, Hans Bakker <[hidden email]> wrote:
>>
>> Again, as discussed at the ApacheCon in Austin we should start setting up a plan how to best move the ERP application to the Moqui framework. Moqui should not be part of the Apache foundation however the ERP application should remain there.
>>
>> Not only will it improve development of the ERP system but also will establish a clean separation between application and frameworks and hopefully getting David Jones back into the project.
>>
>> Yes, I realize i open the pandora box :-) but we need to make some major decisions....
> I'll write this general reply with my OFBiz hat on, not my Moqui one. For Moqui Framework being used by OFBiz would be fantastic. It would bring a lot of well needed use and attention to the project and get it to a level that would take much longer with the current pace of growth. The growth is increasing, but it's nothing like the early years of OFBiz when the marketplace was so different... at that time OFBiz was unique as there weren't many feature-rich open source ecommerce or ERP systems, especially not in Java! I still find it amazing that OFBiz took off as much as it did... I was 23 years old when I started it, and only had 2 years of full-time development work behind me, and only 1 year of that was on ecommerce and ERP systems. Andrew had more experience with custom ecommerce development, but mostly in Perl IIRC.
>
> Anyway, enough nostalgia, back to the present.
>
> Using Moqui Framework in OFBiz would involve some really significant changes. The Moqui API is much cleaner (and everything is available through the single ExecutionContext class), but much different from the scattered static classes of the OFBiz framework. It may be possible to refactor much of the code with some regex search/replace wizardry, but there is a LOT of code in OFBiz to change.
>
> The data model and to some extent service definitions would be easy. I have some FTL templates for transforming those that I'd be happy to share (they are in a private repo right now). I used these to create the little Moqui component that has the OFBiz data model from version 10.04 which I used with a client to run a sort of OFBiz/Moqui hybrid. On that note... if anyone wants to experiment with this that might be a good place to start: get the latest data model definitions in a Moqui component, deploy the Moqui WAR in the same servlet container as OFBiz (just drop it in an OFBiz component) and then run them in parallel accessing the same DB and play with migrating a few screens/etc.
>
> IMO the biggest questions/concerns should be:
>
> 1. the significant effort required to do the migration
> 2. the impact on current users and applications
>
> OFBiz would end up as a very different beast after such changes, there is no way around it. For example screen hierarchies, nesting, and URLs are handled totally different in Moqui. There are some very cool newer open source tools used in Moqui, and some cool features in Moqui that don't (yet) exist in OFBiz, and many of the more advanced and recent ones aren't mentioned here, but this is a basic list of fundamental differences between the two frameworks (see the "OFBiz: How does it compare to Moqui?" section near the bottom):
>
> http://www.moqui.org/framework/index.html
>
> OFBiz could do a custom set of FTL macros to transform screens and forms into HMTL/etc, but OOTB the UI is very different. This isn't just look and feel but also the approach to UI design. For example there are no lookup windows, other widgets and approaches are used instead (though those could be added... I just haven't found the need compared with other approaches that are often cleaner and easier for users). Looking at the demo server you'll see the big differences pretty quickly:
>
> http://demo.moqui.org/
>
> To go a deeper the Moqui book covers most of the framework and is available here:
>
> http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf
>
> Is it a good idea? I'm not sure about that. Both concerns 1 and 2 above are a big deal. It would be a huge change for OFBiz users and not in any way backwards compatible. Not only the code in OFBiz but also all custom code built on OFBiz would have to be changed to update to the newest versions. Given the community and user driven reality of OFBiz, my guess is that the current architecture would never be fully abandoned and would live on into the foreseeable future with both bug fixes and new features going into it.
>
> On the other hand the growth potential is pretty substantial. Code in OFBiz would end up being much cleaner and smaller. Security (especially authz) could be ripped out of thousands of places and put in simple database configuration. There would be better ability to handle custom and generic RESTful and other web services. Elasticsearch is there ready to use for both full text search and analytics (ie using Elasticsearch as a distributed and efficient OLAP data store... with ETL done through simple mapping configuration as opposed to custom code). New developers would be able to get started much faster and work more efficiently, and experienced developers would be able to build custom apps faster than they've ever experienced. With Moqui and Mantle already to a pretty good place last fall I was able to build a 400 form ERP application in about 4 months working full time, and now Moqui/Mantle are far better because of this and other efforts going on so the time would be even less.
>
> To muddy the waters more: the data model, logic, and UI in OFBiz have a lot of room for improvement. I made dozens of general changes, resulting in hundreds of physical changes, to the OFBiz data model when rewriting it for the Mantle Business Artifacts project. Most, but not all, of the general changes are listed here:
>
> https://github.com/moqui/mantle/blob/master/mantle-udm/Planning.txt
>
> On top of that there is the logic layer. Mantle has a 100% service logic layer unlike the object/service hybrid in OFBiz. There is a LOT of functionality for order processing in OFBiz, including a few features still not implemented in Mantle (though Mantle does have a few that aren't in OFBiz), but that part of OFBiz is one of the most difficult and error-prone parts to work on or customize. I've been on various contracts where they gave up making changes there so wanted to hire it out... and I've turned down a few because I hate working on it too! The Mantle approach gets rid of the whole ShoppingCart object idea (and the various related objects and services to get it to do general stuff) and just puts the cart in the database as a tentative order. This eliminates the need for many thousands of lines of code, and makes it more flexible and faster at the same time.
>
> This is where I question whether it is a good idea to just replace the framework and leave all else as-is in OFBiz. I know very well that bringing this up is likely to stall the discussion and reduce the chances of OFBiz ever using Moqui, and the great thing for Moqui and OFBiz that it could be. Still, the effort required to do that migration is significant and IMO it would be far less effort to start with Moqui and Mantle and basically rewrite OFBiz to be a comprehensive business automation application suite, just as it is now, but cleaned up and streamlined for both developers and end-users in ways that are only dreamed of for OFBiz right now.
>
> How long would that take? Depending on how many people are interested and get involved and how quickly they come up to speed on Moqui and Mantle (the book linked to above can help a lot with this, it covers the basics of Mantle too), my guess is that it could be to an alpha state and do everything OFBiz currently does and more (on the app level at least) within 6 months. IMO the result would be enough to compete well with projects like Odoo that are currently leapfrogging OFBiz... but are a serious pain to customize compared to OFBiz, and every single one has more restrictive licensing and are corporate backed as opposed to community driven.
>
> This could be shorted with a starting point for the applications, and if there was enough interest theres a chance that I could release the more generic parts of this Moqui-based ERP system that I'm working on. I've already gone through the effort of splitting out the generic screens into an application that runs on its own, and the industry specific ERP that I'm working on simply extends it with additional forms, screens, services, and a few entities (really not bad for an industry where generic ERP systems have totally failed to the very different practices and business processes common in the industry, so nearly all market share is in industry specific systems).
>
> I know that's more than 2 cents of thoughts, even if it may only be worth that. ;) For those who have been around a while you know this sort of LONG email is consistent with my oft lamented style... hopefully it will that will at least bring a few chuckles and maybe some eye-rolling in fond remembrance of novel length mailing list threads.
>
> -David
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

Ron Wheeler
In reply to this post by David E. Jones-2
On 20/04/2015 3:11 PM, David E. Jones wrote:
>> On 20 Apr 2015, at 11:35, Ron Wheeler <[hidden email]> wrote:
>>
>> Would Moqui become a sub-project of OFBiz with distinct deliverable with an Apache license?
>> Or is that too much community?
> IMO they are better as distinct projects. There is a chance Moqui Framework could become a separate ASF project, though the name "Apache Moqui" is oddly contradictory (I chose the name based on Moqui Marbles, but it is also another name for the Hopi tribe). More seriously, these days I like the distributed and moderated approaches used in the Linux kernel more than the community approach mandated by the ASF.
What would be the problem of it being part of OFBiz in the same way that
FOP and Batik are part of the XLMGraphics project or Jetspeed is part of
the Portals project.
A lot less work than a TLP but still benefiting from Apache.
Would not have to call of Apache Moqui. It would just be Moqui , part of
Apache OfBiz

>
> As for community, regardless of the structure the various Moqui projects are now in a good place for a bigger community and it is needed for more significant growth in the projects. There are parallels to OFBiz which was mostly two people until around 2004-2005 when the project exploded (we had other contributors before then, but most not so involved or enduring). Jacopo was the first really strong contributor in 2003, and remains to this day! I'm still looking for a "Jacopo" for Moqui... heck, maybe it'll be Jacopo. ;) (No pressure Jacopo: I know you're a busy man and doing fantastic and important work elsewhere including OFBiz, Hotwax, and other projects you contribute to.)
>
> As for licensing: the public domain "license" is even less restrictive than the Apache 2 license. The one thing that bothers me about the licensing approach, that I'll freely admit but that I'm not sure how to handle better, is the explicit patent grant that is in the Apache 2 license (which made it incompatible with GPL2, though GPL3 has it too so it is "compatible", ie no additional restrictions). In theory this shouldn't be a legal issue because releasing it as public domain means giving up most IP rights, and there is the prior art aspect of it too, but patent courts these days (at least in the USA) are awful and they don't seem to care about prior art unless you pay a few million USD to lawyers along with substantial court fees to get that recognized. In theory it shouldn't be an issue, not sure if it ever has been even for Apache 2 licensed code, but it could be and in theory the terms in the Apache 2 license make it cheaper to defend against patent claims (again in theory... chances are there would still be significant, possibly bankrupting, legal fees to defend against such).
Being a part of an Apache project makes it harder to try to steal the IP
or claim ownership.

>
> -David
>
>
>> On 20/04/2015 1:19 PM, David E. Jones wrote:
>>>> On 20 Apr 2015, at 02:24, Jacques Le Roux <[hidden email]> wrote:
>>>>
>>>> Le 20/04/2015 09:47, Adrian Crum a écrit :
>>>>> Generally speaking, I am in favor of using another framework. I have two reservations about Moqui:
>>>>>
>>>>> 1. It is controlled by a single person - so responsiveness to issues are dependent on that person's availability.
>>>> This is indeed a regression from the current community sharing. On the other hand a such change would not be done in one day, so we would have a long period to experiment in parallel before possibly switching to Moqui.
>>>> I also guess in such cases David could open the Moqui to people he trusts. I though wonder how this would be linked together. Nothing blocking but to be seriously thought about, not only technically but legally. I know it's David's will to share and he proved it already with OFBiz but the licensing aspect is not clear to me http://www.moqui.org/#model.
>>> With Moqui it's no secret that I chose the "code over community" route which is certainly different from the ASF emphasis on community (and my emphasis on community and collaboration from the beginning in OFBiz).
>>>
>>> Moqui Framework is now pretty mature and I have sent out a couple of solicitations (in the LinkedIn group) for more contributors, but I'm in no hurry to bring on other committers/moderators... better to wait until clearly interested and capable people come along. The infrastructure is in place for this on GitHub, ie the main repo is under the "moqui" group and not my personal account any more so it is easy to add others to that group with permission for particular repositories (ie moqui vs mantle, HiveMind, etc).
>>>
>>> Part of the reason I'm less worried about this is the different model for source management that Git makes possible and GitHub makes easy. In other words, the magic of distributed source management. Distributed source management and the moderator model make it possible for "forks" to exist that have variations on the main code base that are available for all and pulled into the main code base by moderators. You don't have to be a moderator to contribute, or even share your code with the world.
>>>
>>> The whole distributed source and moderator model is very different from the community model in OFBiz, and overall better for some things and worse for others. Many big projects use this model, including the Linux kernel which is probably the biggest and the use of this model for the Linux kernel is exactly where git came from.
>>>
>>> My guess is that if OFBiz started using Moqui Framework one or more current OFBiz committers would become moderators with commit access to the main Moqui Framework repository.
>>>
>>>>> 2. It repeats a lot of mistakes that have been made in OFBiz, so those things will need to be fixed again in Moqui after we bring it on board.
>>>> Indeed, a lot of fixes have been done recently in OFBiz which is battle tested for years. Moqui though certainly well done, is still young and we would need to compare them, point by point.
>>> I'd love to hear more detail on this. I know one criticism in the past from Adrian is Moqui's approach to object type conversions, especially in the Entity Facade (the part of Moqui similar to the OFBiz Entity Engine). In some parts of Moqui, like for service parameters, it uses the Groovy type conversion which is pretty good but isn't a pluggable type conversion framework as I'm sure Adrian would like to see... but that honestly I still have yet to find a need for.
>>>
>>> On the entity level I prefer the current approach, mostly for performance reasons. In recent changes to the framework for performance improvements (which were significant... Moqui now getting around 15,000 entity ops per second as opposed to 3,000 before the latest changes, and close to 300 in the original version of Moqui though that was on an older laptop/etc and before ANY optimizations where done). This does limit the types available for entity fields, but is that really an issue? You're going to a database through JDBC, and really just the least common denominator of types available in databases to cleanly run on various ones, so there aren't many options in the first place! We can take advantage of that for simpler code and better performance.
>>>
>>>>> Neither one is a show-stopper for me.
>>>> Same here, just cautious.
>>> Caution is good in this case... to be honest I'm not sure using Moqui Framework in OFBiz is a good idea (as I've mentioned before), will write more on that in another reply.
>>>
>>> -David
>>>
>>>
>>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: [hidden email]
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>


--
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: Discussion: Replace framework by Moqui.

Nicolas Malin-2
Le 20/04/2015 21:48, Ron Wheeler a écrit :
>
> Would not have to call of Apache Moqui. It would just be Moqui , part
> of Apache OfBiz
Ron, in other word, you propose to fork Moqui into Apache OFBiz ?

Nicolas
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: Replace framework by Moqui.

Adrian Crum-3
In reply to this post by David E. Jones-2
On 4/20/2015 7:39 PM, David E. Jones wrote:
> This is where I question whether it is a good idea to just replace the framework and leave all else as-is in OFBiz. I know very well that bringing this up is likely to stall the discussion and reduce the chances of OFBiz ever using Moqui, and the great thing for Moqui and OFBiz that it could be. Still, the effort required to do that migration is significant and IMO it would be far less effort to start with Moqui and Mantle and basically rewrite OFBiz to be a comprehensive business automation application suite, just as it is now, but cleaned up and streamlined for both developers and end-users in ways that are only dreamed of for OFBiz right now.

The discussions so far have been around just replacing the OFBiz
framework with Moqui. There is a separate discussion going on about
reorganizing higher level artifacts differently.

I was thinking we could create a thunk component to ease the transition
to Moqui. The thunk component would map existing Java packages to the
Moqui API, and then we can make changes to client code as time allows.


Adrian Crum
Sandglass Software
www.sandglass-software.com
1234