Long story short, I'd rather go the complete Moqui way :) But I'm not there
yet, not so far though...
Jacques
Le 20/04/2015 20:39, David E. Jones a écrit :
On 19 Apr 2015, at 22:31, Hans Bakker <[email protected]> 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
