@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 <nicolas.ma...@nereide.fr> 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 <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 >>>>> >>>>> >>>>> >>>>> >>>>>
