Discussion: Replace framework by Moqui.

[Nicolas Malin-2]

>
> 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....
Moqui is very attractive, at this time I think it will be embed in OFBiz
framework and not replace it. Because it's important to have the
backward compatibility (java interface, and xml model reader can be used
to make sure it). It's the OFBiz strong !

My point of view is : no backward compatibility, no discussion :)

Nicolas

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

[Pierre Smits]

@Nicolas: in the end it is code change. Does your point of view reflect a
veto?

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 10:23 PM, Nicolas Malin <[hidden email]>
wrote:

>
>
>> 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....
>>
> Moqui is very attractive, at this time I think it will be embed in OFBiz
> framework and not replace it. Because it's important to have the backward
> compatibility (java interface, and xml model reader can be used to make
> sure it). It's the OFBiz strong !
>
> My point of view is : no backward compatibility, no discussion :)
>
> Nicolas
>
>>
>> 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
>>>
>>>
>>>
>>>

[Ron Wheeler]

On 20/04/2015 3:57 PM, Nicolas Malin wrote:
> 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
>
I am not proposing anything.
I am pointing out that
1) there are ways to get the Moqui project into a community that will
use it as the basis of things that it wants
2) Apache has a history of projects that kept their identity as a
separate deliverable from the other products in the same Apache TLP.
3) Apache will then become the defender of the IP.

It is really up to David and the PMC to see if this solves a sufficient
number of problems to make this a viable solution.

As others have pointed out, there are downsides to switching frameworks
and the OFBiz community is going to have to be willing to support 2
frameworks and possibly 2 versions of many components for some time.

If the long-term goal is to offer an OFBiz with Moqui as its base, it
would be a good idea to setup Moqui as an OFBiz sub-project sooner
rather than later and give David the support and legal protection that
he seems to be looking for while we start the process of rewritting
OFBiz to support both frameworks. This would ensure that Moqui is
supported and is available under an Apache license which will make it
much easier to include in OFBiz when and if that happens. It would also
give David a chance to build a team of supporters without having to deal
with all of Apache's requirements except as part of OFBiz.
If Moqui is never used as the framework for the ERP , it would still fit
in as a framework alternative for the OFBiz framework and both could be
marketed under the OFBiz trademark.

Ron


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

[David E. Jones-2]

> On 20 Apr 2015, at 12:48, Ron Wheeler <[hidden email]> wrote:
>
> 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

XML Graphics and Portals are both umbrella projects, meant to have sub-projects, and OFBiz is not. OFBiz could be restructured that way, and perhaps even have sub-projects without that restructuring sort of like the Jackrabbit Oak project, but still not sure if it makes sense. On that note: if a Moqui-based (or Moqui and Mantle based) version of OFBiz were built it might make sense as a sub-project just like Oak is of Jackrabbit. On a far side note: Oak looks great but I wish it ran on something other than MongoDB so it could be embedded for dev and smaller deployments!

The process of becoming a TLP isn't that much of a concern to me. It takes time, but is worth it to establish a firm foundation for the project going forward.

The main issues that concern me are the various and changing policies of the ASF. I have a hard time seeing the point of trademarks for open source projects, for example. The community model is another concern, I don't like the structure as much as certain alternatives in the open source world (even if I used to think it was the best approach, or at least something similar to the ASF approach). It may be possible to manage a more distributed community and code base with various fork repositories and feature/issue branches in the style of git (ie actually using git within the ASF).

During incubation the biggest community risk is _forcing_ a certain number of committers and PMC members. I don't want to scrape to include people in these roles as they are vital to the future of the project. I would rather let people come along, express interest, and thoroughly prove merit before they take on such a role.

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

Because of the ASF legal fund?

-David

[David E. Jones-2]

> On 20 Apr 2015, at 13:21, Adrian Crum <[hidden email]> wrote:
>
> 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.

My first thought in this is it would be messy. :) Moqui objects have a lifecycle with init/destroy methods, especially the ExecutionContext which is created for each general operation such as processing an HTTP request (for web page, web service call, whatever) or running a background service job. There is a static method to get the main ExecutionContextFactory, but then you can only ever have one of those (usually not a big deal), and from there get the current ExecutionContext or create one. When you're done with the ExecutionContext it needs to be destroyed though.

The Moqui features that aren't in the OFBiz framework anywhere could be accessed directly, so that shouldn't be an issue. There could be issues in the other direction, parts of the OFBiz framework that are left out of Moqui in favor of other tools (these could be wrapped as well... though unwrapping them is much cleaner... I guess there are already a dozen or more classes in the OFBiz framework that are just thin veneers around other tools!) or that just don't exist because they didn't seem useful and no need for them has come up.

Anyway, it a good thought, might be interesting to try...

-David

[Pierre Smits]

I wonder how that would work. At some moment in time a two track approach
is more taxing than a one track. In the past we had commit wars, with this
(two long term tracks) we get that again at a whole different (higher
level).

To be a bit sarcastic here: there are also other Business Solutions
frameworks in other Apache projects (e.g. Wicket, Cordova, others). Why
don't we also reach out to those and bind them under the OFBiz ring.

Choices need to be made. You can't have it both ways. The same goes with
moving forward vs backward compatibility.

Nevertheless, incorporating/embedding another framework is a long term
effort. That effort should definitely start/evolve in a separate branch.
But the decision whether to or not to starts needs to be made before that.

Nevertheless, there are also the concerns expressed earlier by Adrian. We
should not cast those aside without proper consideration.

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 10:29 PM, Ron Wheeler <
[hidden email]> wrote:

> On 20/04/2015 3:57 PM, Nicolas Malin wrote:
>
>> 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
>>
>>  I am not proposing anything.
> I am pointing out that
> 1) there are ways to get the Moqui project into a community that will use
> it as the basis of things that it wants
> 2) Apache has a history of projects that kept their identity as a separate
> deliverable from the other products in the same Apache TLP.
> 3) Apache will then become the defender of the IP.
>
> It is really up to David and the PMC to see if this solves a sufficient
> number of problems to make this a viable solution.
>
> As others have pointed out, there are downsides to switching frameworks
> and the OFBiz community is going to have to be willing to support 2
> frameworks and possibly 2 versions of many components for some time.
>
> If the long-term goal is to offer an OFBiz with Moqui as its base, it
> would be a good idea to setup Moqui as an OFBiz sub-project sooner rather
> than later and give David the support and legal protection that he seems to
> be looking for while we start the process of rewritting OFBiz to support
> both frameworks. This would ensure that Moqui is supported and is available
> under an Apache license which will make it much easier to include in OFBiz
> when and if that happens. It would also give David a chance to build a team
> of supporters without having to deal with all of Apache's requirements
> except as part of OFBiz.
> If Moqui is never used as the framework for the ERP , it would still fit
> in as a framework alternative for the OFBiz framework and both could be
> marketed under the OFBiz trademark.
>
> Ron
>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: [hidden email]
> skype: ronaldmwheeler
> phone: [phone], ext 102
>
>

[Adam Heath-2]

On 04/20/2015 03:21 PM, Adrian Crum wrote:

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

The maven shade plugin can remap java packages.

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

[Shi Jinghai-3]

+1. Co-existing would be good as the 1st step.

Anyway, I'd suggest Moqui to join Apache, for customers, Apache is a brand means quality. Feel like we all back to 2006 now. David, in apache, you can choose git and use github as a backup like Apache Isis does.


在 2015-4-21，上午4:23，Nicolas Malin <[hidden email]> 写道：

>
>>
>> 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....
> Moqui is very attractive, at this time I think it will be embed in OFBiz framework and not replace it. Because it's important to have the backward compatibility (java interface, and xml model reader can be used to make sure it). It's the OFBiz strong !
>
> My point of view is : no backward compatibility, no discussion :)
>
> Nicolas
>>
>> 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
>>>
>>>
>>>

[Shi Jinghai-4]

+1. Co-exist would be the 1st step.

Anyway, I'd suggest Moqui to join Apache, for customers, Apache is a brand means quality. Feel like we all back to 2006 now. David, in apache, you can choose git and use github as a backup like Apache Isis does.


在 2015-4-21，上午4:23，Nicolas Malin <[hidden email]> 写道：

>
>>
>> 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....
> Moqui is very attractive, at this time I think it will be embed in OFBiz framework and not replace it. Because it's important to have the backward compatibility (java interface, and xml model reader can be used to make sure it). It's the OFBiz strong !
>
> My point of view is : no backward compatibility, no discussion :)
>
> Nicolas
>>
>> 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
>>>
>>>
>>>

[Ron Wheeler]

On 20/04/2015 5:07 PM, David E. Jones wrote:

>> On 20 Apr 2015, at 12:48, Ron Wheeler <[hidden email]> wrote:
>>
>> 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
> XML Graphics and Portals are both umbrella projects, meant to have sub-projects, and OFBiz is not. OFBiz could be restructured that way, and perhaps even have sub-projects without that restructuring sort of like the Jackrabbit Oak project, but still not sure if it makes sense. On that note: if a Moqui-based (or Moqui and Mantle based) version of OFBiz were built it might make sense as a sub-project just like Oak is of Jackrabbit. On a far side note: Oak looks great but I wish it ran on something other than MongoDB so it could be embedded for dev and smaller deployments!
>
> The process of becoming a TLP isn't that much of a concern to me. It takes time, but is worth it to establish a firm foundation for the project going forward.
>
> The main issues that concern me are the various and changing policies of the ASF. I have a hard time seeing the point of trademarks for open source projects, for example.

Not sure if this is key to the current discussion but I would not mind
hearing details of your concerns since we have put a bit of an effort
into that area recently.
> The community model is another concern, I don't like the structure as much as certain alternatives in the open source world (even if I used to think it was the best approach, or at least something similar to the ASF approach). It may be possible to manage a more distributed community and code base with various fork repositories and feature/issue branches in the style of git (ie actually using git within the ASF).
I suspect that the world is heading to git. I am just starting to get
acquanted with it and beginning to feel like a bit of a dinosaur using
SVN for our projects internally.
>
> During incubation the biggest community risk is _forcing_ a certain number of committers and PMC members. I don't want to scrape to include people in these roles as they are vital to the future of the project. I would rather let people come along, express interest, and thoroughly prove merit before they take on such a role.
One of the advantages of joning an existing project is that you are not
affected by the restriction on users and PMC members.
>
>>> 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.
> Because of the ASF legal fund?
and the reputation of Apache, the major sponsors and the number of
companies that would have big problems if the Apache license came under
attack.
Many of the big patent trolls and patent holders use Apache products in
their own products and operations. They would have a hard time
explaining to shareholders the costs and liabilities that they would
suffer if Apache licenses could not be trusted.
>
> -David
>
>
>


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

[Pierre Smits]

Quoting:

I suspect that the world is heading to git. I am just starting to get
acquanted with it and beginning to feel like a bit of a dinosaur using SVN
for our projects internally.


That should be in another thread. Nevertheless, such can be said regarding
a lot of (also unrelated) subjects/things which are still happily used by a
great number. See the 'dinosaur' in this:
http://cdn.static-economist.com/sites/default/files/imagecache/original-size/images/print-edition/20150404_WBC737_0.png

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 Tue, Apr 21, 2015 at 3:43 AM, Ron Wheeler <[hidden email]
> wrote:

> On 20/04/2015 5:07 PM, David E. Jones wrote:
>
>> On 20 Apr 2015, at 12:48, Ron Wheeler <[hidden email]>
>>> wrote:
>>>
>>> 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
>>>
>> XML Graphics and Portals are both umbrella projects, meant to have
>> sub-projects, and OFBiz is not. OFBiz could be restructured that way, and
>> perhaps even have sub-projects without that restructuring sort of like the
>> Jackrabbit Oak project, but still not sure if it makes sense. On that note:
>> if a Moqui-based (or Moqui and Mantle based) version of OFBiz were built it
>> might make sense as a sub-project just like Oak is of Jackrabbit. On a far
>> side note: Oak looks great but I wish it ran on something other than
>> MongoDB so it could be embedded for dev and smaller deployments!
>>
>> The process of becoming a TLP isn't that much of a concern to me. It
>> takes time, but is worth it to establish a firm foundation for the project
>> going forward.
>>
>> The main issues that concern me are the various and changing policies of
>> the ASF. I have a hard time seeing the point of trademarks for open source
>> projects, for example.
>>
> Not sure if this is key to the current discussion but I would not mind
> hearing details of your concerns since we have put a bit of an effort into
> that area recently.
>
>> The community model is another concern, I don't like the structure as
>> much as certain alternatives in the open source world (even if I used to
>> think it was the best approach, or at least something similar to the ASF
>> approach). It may be possible to manage a more distributed community and
>> code base with various fork repositories and feature/issue branches in the
>> style of git (ie actually using git within the ASF).
>>
> I suspect that the world is heading to git. I am just starting to get
> acquanted with it and beginning to feel like a bit of a dinosaur using SVN
> for our projects internally.
>
>>
>> During incubation the biggest community risk is _forcing_ a certain
>> number of committers and PMC members. I don't want to scrape to include
>> people in these roles as they are vital to the future of the project. I
>> would rather let people come along, express interest, and thoroughly prove
>> merit before they take on such a role.
>>
> One of the advantages of joning an existing project is that you are not
> affected by the restriction on users and PMC members.
>
>>
>>  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.
>>>
>> Because of the ASF legal fund?
>>
> and the reputation of Apache, the major sponsors and the number of
> companies that would have big problems if the Apache license came under
> attack.
> Many of the big patent trolls and patent holders use Apache products in
> their own products and operations. They would have a hard time explaining
> to shareholders the costs and liabilities that they would suffer if Apache
> licenses could not be trusted.
>
>
>> -David
>>
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: [hidden email]
> skype: ronaldmwheeler
> phone: [phone], ext 102
>
>
>

[Nicolas Malin-2]

Le 20/04/2015 22:27, Pierre Smits a écrit :
> @Nicolas: in the end it is code change. Does your point of view reflect a
> veto?
If the code change and the backward compatibility is present, no worries.
We are an enterprise automation software not just a framework. Many
companies trust in this stability and it's the main reason that I love
OFBiz.
I think we are relatively smart to don't break it ;)

If I don't need backward compatibility without making customer project
directly with Moqui/mantle, why keep Apache 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 Mon, Apr 20, 2015 at 10:23 PM, Nicolas Malin <[hidden email]>
> wrote:
>
>>
>>> 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....
>>>
>> Moqui is very attractive, at this time I think it will be embed in OFBiz
>> framework and not replace it. Because it's important to have the backward
>> compatibility (java interface, and xml model reader can be used to make
>> sure it). It's the OFBiz strong !
>>
>> My point of view is : no backward compatibility, no discussion :)
>>
>> Nicolas
>>
>>> 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
>>>>
>>>>
>>>>
>>>>

[Pierre Smits]

Nice to have you back and engaged, David. My apologies if I didn't express
that earlier.

Were you at ACNA15 also?

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 Tue, Apr 21, 2015 at 8:59 AM, Pierre Smits <[hidden email]>
wrote:

> Quoting:
>
> I suspect that the world is heading to git. I am just starting to get
> acquanted with it and beginning to feel like a bit of a dinosaur using SVN
> for our projects internally.
>
>
> That should be in another thread. Nevertheless, such can be said regarding
> a lot of (also unrelated) subjects/things which are still happily used by a
> great number. See the 'dinosaur' in this:
> http://cdn.static-economist.com/sites/default/files/imagecache/original-size/images/print-edition/20150404_WBC737_0.png
>
> 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 Tue, Apr 21, 2015 at 3:43 AM, Ron Wheeler <
> [hidden email]> wrote:
>
>> On 20/04/2015 5:07 PM, David E. Jones wrote:
>>
>>> On 20 Apr 2015, at 12:48, Ron Wheeler <[hidden email]>
>>>> wrote:
>>>>
>>>> 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
>>>>
>>> XML Graphics and Portals are both umbrella projects, meant to have
>>> sub-projects, and OFBiz is not. OFBiz could be restructured that way, and
>>> perhaps even have sub-projects without that restructuring sort of like the
>>> Jackrabbit Oak project, but still not sure if it makes sense. On that note:
>>> if a Moqui-based (or Moqui and Mantle based) version of OFBiz were built it
>>> might make sense as a sub-project just like Oak is of Jackrabbit. On a far
>>> side note: Oak looks great but I wish it ran on something other than
>>> MongoDB so it could be embedded for dev and smaller deployments!
>>>
>>> The process of becoming a TLP isn't that much of a concern to me. It
>>> takes time, but is worth it to establish a firm foundation for the project
>>> going forward.
>>>
>>> The main issues that concern me are the various and changing policies of
>>> the ASF. I have a hard time seeing the point of trademarks for open source
>>> projects, for example.
>>>
>> Not sure if this is key to the current discussion but I would not mind
>> hearing details of your concerns since we have put a bit of an effort into
>> that area recently.
>>
>>> The community model is another concern, I don't like the structure as
>>> much as certain alternatives in the open source world (even if I used to
>>> think it was the best approach, or at least something similar to the ASF
>>> approach). It may be possible to manage a more distributed community and
>>> code base with various fork repositories and feature/issue branches in the
>>> style of git (ie actually using git within the ASF).
>>>
>> I suspect that the world is heading to git. I am just starting to get
>> acquanted with it and beginning to feel like a bit of a dinosaur using SVN
>> for our projects internally.
>>
>>>
>>> During incubation the biggest community risk is _forcing_ a certain
>>> number of committers and PMC members. I don't want to scrape to include
>>> people in these roles as they are vital to the future of the project. I
>>> would rather let people come along, express interest, and thoroughly prove
>>> merit before they take on such a role.
>>>
>> One of the advantages of joning an existing project is that you are not
>> affected by the restriction on users and PMC members.
>>
>>>
>>>  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.
>>>>
>>> Because of the ASF legal fund?
>>>
>> and the reputation of Apache, the major sponsors and the number of
>> companies that would have big problems if the Apache license came under
>> attack.
>> Many of the big patent trolls and patent holders use Apache products in
>> their own products and operations. They would have a hard time explaining
>> to shareholders the costs and liabilities that they would suffer if Apache
>> licenses could not be trusted.
>>
>>
>>> -David
>>>
>>>
>>>
>>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: [hidden email]
>> skype: ronaldmwheeler
>> phone: [phone], ext 102
>>
>>
>>
>

[Pierre Smits]

@Nicolas: The questions you raise are vaild. And ever present. Each will
find his/her own justification for the choice made. This project is not
about that. It offers a choice, based on a shared vision.

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 Tue, Apr 21, 2015 at 9:48 AM, Nicolas Malin <[hidden email]>
wrote:

> Le 20/04/2015 22:27, Pierre Smits a écrit :
>
>> @Nicolas: in the end it is code change. Does your point of view reflect a
>> veto?
>>
> If the code change and the backward compatibility is present, no worries.
> We are an enterprise automation software not just a framework. Many
> companies trust in this stability and it's the main reason that I love
> OFBiz.
> I think we are relatively smart to don't break it ;)
>
> If I don't need backward compatibility without making customer project
> directly with Moqui/mantle, why keep Apache 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 Mon, Apr 20, 2015 at 10:23 PM, Nicolas Malin <[hidden email]
>> >
>> wrote:
>>
>>
>>>  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....
>>>>
>>>>  Moqui is very attractive, at this time I think it will be embed in
>>> OFBiz
>>> framework and not replace it. Because it's important to have the backward
>>> compatibility (java interface, and xml model reader can be used to make
>>> sure it). It's the OFBiz strong !
>>>
>>> My point of view is : no backward compatibility, no discussion :)
>>>
>>> Nicolas
>>>
>>>  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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>

[Jacques Le Roux]

Le 21/04/2015 09:48, Nicolas Malin a écrit :
> Le 20/04/2015 22:27, Pierre Smits a écrit :
>> @Nicolas: in the end it is code change. Does your point of view reflect a
>> veto?
> If the code change and the backward compatibility is present, no worries.
> We are an enterprise automation software not just a framework. Many companies trust in this stability and it's the main reason that I love OFBiz.
> I think we are relatively smart to don't break it ;)
>
> If I don't need backward compatibility without making customer project directly with Moqui/mantle, why keep Apache OFBiz ?
>

That's the main point, thanks Nicolas!

Jacques

>
>>
>> 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 10:23 PM, Nicolas Malin <[hidden email]>
>> wrote:
>>
>>>
>>>> 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....
>>>>
>>> Moqui is very attractive, at this time I think it will be embed in OFBiz
>>> framework and not replace it. Because it's important to have the backward
>>> compatibility (java interface, and xml model reader can be used to make
>>> sure it). It's the OFBiz strong !
>>>
>>> My point of view is : no backward compatibility, no discussion :)
>>>
>>> Nicolas
>>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>

[David E. Jones-2]

Fascinating diagram in that link from The Economist. I had no idea IBM had such huge market share in the past! It's good to see the industry becoming more "distributed", ie market share spread across a larger number of companies.

Thanks, nice to be engaged in the project here and there. No, I wasn't at ApacheCon last week, a bit outside my current budgets (both time and money), especially with competing priorities like visiting family and friends... which I'm sure is the case for many would have liked to attend.

-David

> On 21 Apr 2015, at 01:12, Pierre Smits <[hidden email]> wrote:
>
> Nice to have you back and engaged, David. My apologies if I didn't express
> that earlier.
>
> Were you at ACNA15 also?
>
> 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 Tue, Apr 21, 2015 at 8:59 AM, Pierre Smits <[hidden email]>
> wrote:
>
>> Quoting:
>>
>> I suspect that the world is heading to git. I am just starting to get
>> acquanted with it and beginning to feel like a bit of a dinosaur using SVN
>> for our projects internally.
>>
>>
>> That should be in another thread. Nevertheless, such can be said regarding
>> a lot of (also unrelated) subjects/things which are still happily used by a
>> great number. See the 'dinosaur' in this:
>> http://cdn.static-economist.com/sites/default/files/imagecache/original-size/images/print-edition/20150404_WBC737_0.png
>>
>> 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 Tue, Apr 21, 2015 at 3:43 AM, Ron Wheeler <
>> [hidden email]> wrote:
>>
>>> On 20/04/2015 5:07 PM, David E. Jones wrote:
>>>
>>>> On 20 Apr 2015, at 12:48, Ron Wheeler <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> 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
>>>>>
>>>> XML Graphics and Portals are both umbrella projects, meant to have
>>>> sub-projects, and OFBiz is not. OFBiz could be restructured that way, and
>>>> perhaps even have sub-projects without that restructuring sort of like the
>>>> Jackrabbit Oak project, but still not sure if it makes sense. On that note:
>>>> if a Moqui-based (or Moqui and Mantle based) version of OFBiz were built it
>>>> might make sense as a sub-project just like Oak is of Jackrabbit. On a far
>>>> side note: Oak looks great but I wish it ran on something other than
>>>> MongoDB so it could be embedded for dev and smaller deployments!
>>>>
>>>> The process of becoming a TLP isn't that much of a concern to me. It
>>>> takes time, but is worth it to establish a firm foundation for the project
>>>> going forward.
>>>>
>>>> The main issues that concern me are the various and changing policies of
>>>> the ASF. I have a hard time seeing the point of trademarks for open source
>>>> projects, for example.
>>>>
>>> Not sure if this is key to the current discussion but I would not mind
>>> hearing details of your concerns since we have put a bit of an effort into
>>> that area recently.
>>>
>>>> The community model is another concern, I don't like the structure as
>>>> much as certain alternatives in the open source world (even if I used to
>>>> think it was the best approach, or at least something similar to the ASF
>>>> approach). It may be possible to manage a more distributed community and
>>>> code base with various fork repositories and feature/issue branches in the
>>>> style of git (ie actually using git within the ASF).
>>>>
>>> I suspect that the world is heading to git. I am just starting to get
>>> acquanted with it and beginning to feel like a bit of a dinosaur using SVN
>>> for our projects internally.
>>>
>>>>
>>>> During incubation the biggest community risk is _forcing_ a certain
>>>> number of committers and PMC members. I don't want to scrape to include
>>>> people in these roles as they are vital to the future of the project. I
>>>> would rather let people come along, express interest, and thoroughly prove
>>>> merit before they take on such a role.
>>>>
>>> One of the advantages of joning an existing project is that you are not
>>> affected by the restriction on users and PMC members.
>>>
>>>>
>>>> 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.
>>>>>
>>>> Because of the ASF legal fund?
>>>>
>>> and the reputation of Apache, the major sponsors and the number of
>>> companies that would have big problems if the Apache license came under
>>> attack.
>>> Many of the big patent trolls and patent holders use Apache products in
>>> their own products and operations. They would have a hard time explaining
>>> to shareholders the costs and liabilities that they would suffer if Apache
>>> licenses could not be trusted.
>>>
>>>
>>>> -David
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: [hidden email]
>>> skype: ronaldmwheeler
>>> phone: [phone], ext 102
>>>
>>>
>>>
>>

[Pierre Smits]

Yes, in the past many also have claimed that that Dinosaur would be extinct
in the short future...

I can relate to the other priorities and constraints. Should you be in the
position: there might be an OFBiz track again at ACEU15 in Budapest later
this year. Though I am not sure regarding the certainty of that. Directions
at another level have changed...

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 Tue, Apr 21, 2015 at 12:12 PM, David E. Jones <[hidden email]> wrote:

>
> Fascinating diagram in that link from The Economist. I had no idea IBM had
> such huge market share in the past! It's good to see the industry becoming
> more "distributed", ie market share spread across a larger number of
> companies.
>
> Thanks, nice to be engaged in the project here and there. No, I wasn't at
> ApacheCon last week, a bit outside my current budgets (both time and
> money), especially with competing priorities like visiting family and
> friends... which I'm sure is the case for many would have liked to attend.
>
> -David
>
>
> > On 21 Apr 2015, at 01:12, Pierre Smits <[hidden email]> wrote:
> >
> > Nice to have you back and engaged, David. My apologies if I didn't
> express
> > that earlier.
> >
> > Were you at ACNA15 also?
> >
> > 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 Tue, Apr 21, 2015 at 8:59 AM, Pierre Smits <[hidden email]>
> > wrote:
> >
> >> Quoting:
> >>
> >> I suspect that the world is heading to git. I am just starting to get
> >> acquanted with it and beginning to feel like a bit of a dinosaur using
> SVN
> >> for our projects internally.
> >>
> >>
> >> That should be in another thread. Nevertheless, such can be said
> regarding
> >> a lot of (also unrelated) subjects/things which are still happily used
> by a
> >> great number. See the 'dinosaur' in this:
> >>
> http://cdn.static-economist.com/sites/default/files/imagecache/original-size/images/print-edition/20150404_WBC737_0.png
> >>
> >> 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 Tue, Apr 21, 2015 at 3:43 AM, Ron Wheeler <
> >> [hidden email]> wrote:
> >>
> >>> On 20/04/2015 5:07 PM, David E. Jones wrote:
> >>>
> >>>> On 20 Apr 2015, at 12:48, Ron Wheeler <[hidden email]
> >
> >>>>> wrote:
> >>>>>
> >>>>> 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
> >>>>>
> >>>> XML Graphics and Portals are both umbrella projects, meant to have
> >>>> sub-projects, and OFBiz is not. OFBiz could be restructured that way,
> and
> >>>> perhaps even have sub-projects without that restructuring sort of
> like the
> >>>> Jackrabbit Oak project, but still not sure if it makes sense. On that
> note:
> >>>> if a Moqui-based (or Moqui and Mantle based) version of OFBiz were
> built it
> >>>> might make sense as a sub-project just like Oak is of Jackrabbit. On
> a far
> >>>> side note: Oak looks great but I wish it ran on something other than
> >>>> MongoDB so it could be embedded for dev and smaller deployments!
> >>>>
> >>>> The process of becoming a TLP isn't that much of a concern to me. It
> >>>> takes time, but is worth it to establish a firm foundation for the
> project
> >>>> going forward.
> >>>>
> >>>> The main issues that concern me are the various and changing policies
> of
> >>>> the ASF. I have a hard time seeing the point of trademarks for open
> source
> >>>> projects, for example.
> >>>>
> >>> Not sure if this is key to the current discussion but I would not mind
> >>> hearing details of your concerns since we have put a bit of an effort
> into
> >>> that area recently.
> >>>
> >>>> The community model is another concern, I don't like the structure as
> >>>> much as certain alternatives in the open source world (even if I used
> to
> >>>> think it was the best approach, or at least something similar to the
> ASF
> >>>> approach). It may be possible to manage a more distributed community
> and
> >>>> code base with various fork repositories and feature/issue branches
> in the
> >>>> style of git (ie actually using git within the ASF).
> >>>>
> >>> I suspect that the world is heading to git. I am just starting to get
> >>> acquanted with it and beginning to feel like a bit of a dinosaur using
> SVN
> >>> for our projects internally.
> >>>
> >>>>
> >>>> During incubation the biggest community risk is _forcing_ a certain
> >>>> number of committers and PMC members. I don't want to scrape to
> include
> >>>> people in these roles as they are vital to the future of the project.
> I
> >>>> would rather let people come along, express interest, and thoroughly
> prove
> >>>> merit before they take on such a role.
> >>>>
> >>> One of the advantages of joning an existing project is that you are not
> >>> affected by the restriction on users and PMC members.
> >>>
> >>>>
> >>>> 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.
> >>>>>
> >>>> Because of the ASF legal fund?
> >>>>
> >>> and the reputation of Apache, the major sponsors and the number of
> >>> companies that would have big problems if the Apache license came under
> >>> attack.
> >>> Many of the big patent trolls and patent holders use Apache products in
> >>> their own products and operations. They would have a hard time
> explaining
> >>> to shareholders the costs and liabilities that they would suffer if
> Apache
> >>> licenses could not be trusted.
> >>>
> >>>
> >>>> -David
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Ron Wheeler
> >>> President
> >>> Artifact Software Inc
> >>> email: [hidden email]
> >>> skype: ronaldmwheeler
> >>> phone: [phone], ext 102
> >>>
> >>>
> >>>
> >>
>
>

[Adrian Crum-3]

This has been discussed for nearly a week now. Shall we start a vote?

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

[Jacopo Cappellato-5]

The discussion is interesting and fascinating but in this thread completely different ideas have been expressed: from forking Moqui into OFBiz to rewriting OFBiz applications from scratch on top of Moqui etc...

My vote will be negative if the vote will be as generic as "replace OFBiz framework with Moqui" is because it would not be an actionable item and there could be 1000 totally different ways to implement it.

Jacopo


On Apr 26, 2015, at 1:58 PM, Adrian Crum <[hidden email]> wrote:

> This has been discussed for nearly a week now. Shall we start a vote?
>
> 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
>>
>>

[Adrian Crum-3]

How about "Replace framework core functionality - like entity engine,
service engine, and security with Moqui."

Is that specific enough?

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/26/2015 1:47 PM, Jacopo Cappellato wrote:

> The discussion is interesting and fascinating but in this thread completely different ideas have been expressed: from forking Moqui into OFBiz to rewriting OFBiz applications from scratch on top of Moqui etc...
>
> My vote will be negative if the vote will be as generic as "replace OFBiz framework with Moqui" is because it would not be an actionable item and there could be 1000 totally different ways to implement it.
>
> Jacopo
>
>
> On Apr 26, 2015, at 1:58 PM, Adrian Crum <[hidden email]> wrote:
>
>> This has been discussed for nearly a week now. Shall we start a vote?
>>
>> 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
>>>
>>>
>