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
