> On 19 Apr 2015, at 22:31, Hans Bakker <mailingl...@antwebsystems.com> 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
