+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 <nicolas.ma...@nereide.fr> 写道:

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



Reply via email to