From: "Jacopo Cappellato" <jacopo.cappell...@hotwaxmedia.com>
There are so many interesting topics in this thread and for now I will
comment on few of them (in spare order):
1) backward compatibility: we already have to stable release branches (and
we will probably create another one soon) and users can
use them and be sure that future releases *within* the branch will be
backward compatible; I mean that 10.04.01, 10.04.02,
10.04.03 etc... will be backward compatible with 10.04 but not with the
09.04 series; future release branches can (and in my
opinion *should*) be free to break backward compatibility; of course the
community, or even better, commercial vendors could
create migration scripts for, let's say, users of 09.04 series to help
them migrate t the 10.04 series; but this is not something
that the community *has* to do; it is important that the history behind
OFBiz is treated as a valuable asset of the project and
not as an burden; to summarize: backward compatibility should be
considered only for the commits of a given release branch and
should not be a limitation for development in the trunk
The migration scripts idea (especially if commercial vendors are involved)
is a very good idea. This could foster an ecosystem
around OFBiz with differenret versions still compatible. Even without it, I
think going the Tomcat way (as David outlined, or HTTPD
also) would relieve us of the burden of updating endlessly versions. It's
already the case, the verion 4.0 is ignored by us, we
don't update it
anymore. I have even created a specific Jira for valuable R4.0 patches
https://issues.apache.org/jira/browse/OFBIZ-3268
2) refactoring the OFBiz framework: I would be very happy to discuss and
implement a newer version of the framework; I think that
we should get a much lighter framework working into the following
directions:
2.0) before any action can be taken we should finally find an agreement
for a definition of the framework; what is it? how should
be used? IMO something like "a framework for building ERP applications
(characterized by extensive relational data model and
several business processes that manage the data) with browser friendly ui"
is a good start
2.a) removing old or not used (by the official applications) artifacts and
tools; ideally we should have one implementation for
each tool required; alternate implementation should go away;
2.b) removing (or at least revisiting the way they have been integrated)
big external chunks of other projects; they could be
moved to a separate "extra" folder (possibly together with part of the 2.a
stuff), not built by default and not included in our
official releases (instead they could be released separately)
2.c) enhance/simplify the tools we want to keep based on the features/best
practices that proved their validity in the history of
the project (in an evolutionary context)
2.d) 2.a, 2.b and 2.c can happen in the trunk and we will update the
official applications to reflect the changes in the framework
(more about this in point 2.e)
2.e) application and special purpose components: at some point we may
realize that, in order to reflect the changes in the
framework, it would be easier to rewrite/refactor (part of) them instead
of updating them; at that point we may create a
freeze/branch of OFBiz and remove the applications from the trunk; then
migrate to the trunk the parts that we want to keep in the
new generation OFBiz; we could even end up with a completely different
structure like: one component for the generic ERP
application (combining together part of several existing applications like
party, product, order etc... that are already
interdependent) plus a series of vertical components (still rather
generic); or one generic component containing generic business
logic (services) and data models for a generic ERP and then several
different components with different ui for different
industries (like one for retailers, one for manufacturers etc...)
Good ideas, but I'm afraid we still lack human ressources for this to
happen, at least at short/mid term. Also one David point (even
if not in the 7 list) is he wants a better control of code access
permissions...
3) issues with bureaucracy: it is definitely true that being part of the
ASF oblige us to follow and respect some rules; this is
sometime a pain, especially when the rules conflicts with the greater good
of the project (see for example the issues with the ASF
resources that we were forced to adopt); however I don't think that the
issues we see in the community and in OFBiz are caused by
this or by the PMC; I think that the main issues are caused by the
attitude of people working in the community, by conflicting
goals and expectations, by the lack of a shared goal (or by the hidden
presence of several conflicting personal goals), by the
huge size of OFBiz and by its long history; these are indeed issues that
we have to tackle and try to resolve together with a
positive attitude but they could happen in every other big group of people
working with different goals on the same shared
resource; we should not blame the ASF or the PMC for this
I can't agree more. Note though that infra team has been kind enough to
double our memory ressources recently. It was a bit of work
to convince them, but they are open and happy to help, not a blind
bureaucracy! Now, since almost a month, we have *any issues* with
the demo instances, and I'm very happy with that.
Most of the time we have to be patient when a conflict occurs between
committers. It's often limited human ressources and pressure
of time which raises those conflicts, Zen attitude helps then (I speak for
myself ;o). But we should never forget those issues when
they arise and discuss as much as needed. Else one day they come back with
more force and sometimes it's too late to handle them.
My 2cts
Jacques
Kind regards,
Jacopo
On Jan 26, 2011, at 5:45 AM, Adrian Crum wrote:
Many of the things listed here have been discussed, and as far as I can
tell, there is no objection to making those changes - we
just need the manpower to do it.
Item #7 has been discussed and there hasn't been any argument against
that change - except that it touches on the
backwards-compatibility issue. And I'm going to use this opportunity to
address that issue.
Some of the changes mentioned here wouldn't affect any of my projects -
because I don't attempt to patch or modify the
framework - I only build applications on it. Other changes mentioned here
would make application development easier.
The other day Ryan Foster described the backwards-compatibility talk as a
mantra. I view it as more of a straw man. Five days ago
I posed this question to the user mailing list:
"Would you, as an end user of OFBiz, knowing that the OFBiz project could
be improved greatly - but at the cost of some backward
incompatibility - accept the changes? If yes, how often would
backwards-incompatible changes be acceptable?"
It is interesting to note that in a list of over 400 subscribers, no one
has replied.
The most vocal proponents of backwards-compatibility (in the framework)
are a few players who have modified the framework
locally. As a community, do we really want to allow those few members to
stifle innovation?
Some users claimed the updated Flat Grey visual theme wasn't "backwards
compatible." What does that even mean? Some colors and
background images were changed - how is that backwards incompatible?
To be fair, I have been an advocate for backwards-compatibility. But that
has been for things that break application
functionality.
At the least, there needs to be a compromise. At best, there needs to be
acceptance of the possibility of future versions that
are not backwards compatible with previous versions. That concept is not
new or revolutionary - it goes on in every software
project, both open source and commercial.
David has some great ideas, but he feels compelled to start over from
scratch to implement them. From my perspective, that's a
tragedy. One of the project's founders feels the need to start another
project as a last resort to make the project he originally
started better. Does that make sense?
I don't want to use Moqui. It's an unfinished framework controlled by one
person and it has no applications built around it.
Bottom line - it's not an option. What I want is Moqui's innovations in
OFBiz.
I believe it's time we have a serious discussion about this. Users have
commented that there is no plan for OFBiz - what is
planned for its future? They're right. Maybe we should come up with some
plans, or some kind of path to the future.
I propose we put all the cards on the table. Where do we go from here?
Continue on our present path and have competing projects
that improve on OFBiz technology? Try to keep innovation in the project
at the expense of some backwards incompatibility?
Maintain backwards compatibility by forking the project to something new?
Or have milestone versions that are clearly marketed as
backwards incompatible with previous milestone versions?
Lately, it seems many of the big players in the OFBiz developer community
have been absent on the mailing list. I understand that
this is a volunteer community, but at the same time, we all have a say,
and that "say" depends on us saying *something.*
So, please say something.
-Adrian
On 1/25/2011 1:53 PM, David E Jones wrote:
On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
On 1/25/11 2:06 AM, David E Jones wrote:
All of that said, now that Moqui is starting to take shape I find the
OFBiz Framework to be cumbersome and inconsistent in
many ways (things that are hard to fix, but that are not surprising
given the pioneering history of the OFBiz Framework).
Those funny quirky things are likely a turn-off to prospective
developers and I'm hoping to remove that impediment to adopting
the approach.
David - you keep saying this..Please provide some examples of
"cumbersome and inconsistent" within the framework. And why not
try and fix these? Instead of reinventing the wheel. What "funny
quirky" things have turned of prospective developers? Do you
have an specific examples?
Yes, I have mentioned these many times especially in the last 2-3 years.
Some of them I have tried to fix in OFBiz itself and
ran into rather large problems. These are not easy changes to make in a
large and mature project like OFBiz, and after trying a
few times I decided that a new framework was the only way forward
(another thing I've written before and made very clear).
These are the things that led to many aspects of the design of Moqui,
and the best summary of them is the document I wrote about
the differences between the Moqui and OFBiz frameworks:
http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
To sum up here are some of the major inconsistencies and annoyances in
the current OFBiz framework that bug me frequently while
I'm developing:
1. XML actions are different in each widget and in the simple-methods;
they share some underlying code but there are so many
differences
2. scriptlets and expressions are a messy combination of BeanShell, UEL,
and Groovy and keeping track of which is a pain, plus
the Groovy syntax and capabilities are SO much better than the others so
I find myself almost always using ${groovy:...} instead
of the default, and in annoying places like the form.field.@use-whenattribute
since it is always BeanShell I just use a set
action to prepare a boolean and then check it in the use-when (BeanShell
is HORRIBLE compared to groovy, especially when
squeezed into XML attributes)
3. the controller.xml file gets HUGE for larger applications, and if
split it becomes harder to find requests and views;
*Screen.xml files also tend to get HUGE with large numbers of screens in
them; both are not organized in the same way as the
application, also generally making things harder to find; views/screens
and requests don't define incoming parameters so when
doing request-redirect you have to specify the parameters to use in a
larger number of places
4. another on the topic of why so many files: service groups and
simple-methods are just XML, why not include them inline in the
service definition (especially for smaller services), and encourage
fewer services per file
5. loading of artifacts is not very lazy, meaning lots of unused
screens, forms, services, entities and so on that are not used
are loaded anyway; also many artifacts are difficult to reload by cache
clearing and so that has limited support in OFBiz; this
slows things down reloading lots of stuff in development, and results in
more resources used than needed in production
6. the deployment model of OFBiz is limited and the use of static fields
for initialization makes it difficult to deploy in
other ways; there are few init/destroy methods and object instances that
would make more deployment models easier and more
flexible; also because of this it is difficult to get data from other
parts of the framework (for example the audit log stuff in
the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId
and visitId down since there is no other good way of
doing it); in other words, the tools don't share a context
7. no API for apps; the framework is made up of an enormous number of
classes that follow a bunch of different "patterns" (in
quotes because the use of the term is generous) because of various
people "cleaning" things up over time (also in quotes because
the use of the term is generous), and there is no distinction between
the API that apps are intended to use and the internal
implementation of that API; this has the nasty side effect of making it
difficult to find the object and method you want, AND it
makes backward compatibility problems REALLY nasty because it gets
people believing that EVERY SINGLE object needs to ALWAYS be
backward compatible... and that results in more and more piles of trash
code lying around over time, and all of that code and
differing patterns makes framework changes error-prone and unnecessarily
difficult (and this is true for some of the app code in
OFBiz too)
I should get back to work... there's a short list anyway...
The trick is how to solve these without abandoning backward
compatibility, and requiring a refactor of much of the framework and
then based on that the updating of massive numbers of application
artifacts... and that is just the stuff in OFBiz itself... not
including everything that everyone else has written outside the project
that they may want to update. And, ALL of that would
have to be retested. Plus, it would take so long to get all of this done
in a branch with huge numbers of changes while others
are making incremental changes in the trunk making it nearly impossible
to merge the branch into the trunk, so it would
basically be a fork anyway...
-David
