@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 <nicolas.ma...@nereide.fr> 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 <d...@me.com> wrote: >> >> 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 >>> >>> >>> >>>
