I think Example should stay in the framework, but get rid of all of
the "showroom" stuff that has been added to it. In other words, keep
it and return it to its original purpose - a very basic component for
new users to understand OFBiz.
I use datafile to connect legacy systems to OFBiz.
I agree that specialpurpose should be slimmed down, but we should
retain one or two components to demonstrate the concept of reusing
artifacts to create custom applications.
-Adrian
Quoting Jacopo Cappellato <jacopo.cappell...@hotwaxmedia.com>:
In the last period the OFBiz project has grown a lot in shape: the
implicitly accepted (or tolerated) strategy operated by the active
committers was that the more features you could add to the official
repository the better was: you make happy the contributors, making
them feel like they are a part of something, and each committer
could manage the code implemented for his/her own projects directly
in the OFBiz codebase.
We operated under the concept that, since the code if "free" and the
author (committer or not) is willing to contribute it, then no one
should/could complain if it is added to the repository, if it
doesn't cause immediate problems to others; all in all it is an
additional feature that may be used by someone else in the future or
if not would simply stay there without causing any harm.
Following this strategy we got a lot of code like for example
Webslinger, seleniumxml, debian packages, all sort of specialpurpose
applications etc...
Since there was not a central and agreed upon roadmap, no one could
really state that a contribution was not a good fit for the project:
each and every committer could add what, in his own personal vision,
was good for the project.
The wrong assumption is that, since the code if "free" then it
doesn't harm to include it. This is completely *wrong*: the code is
not *free* at all because as soon as you add it to the repository
then you add a future cost to the community: you all know that in
the software industry the cost to maintain a piece of code is by far
greater than the cost to write it; and you *have* to maintain the
code unless you want to have and distribute stale code.
And this is exactly what we have now:
* high costs to maintain the code (e.g. I recently spent a lot of
hours to remove the Webslinger component)
* stale/unused/half baked code that causes confusion and bad
impression to user evaluating the quality of our product
The message to all the committers is: when you add code to the
repository, you are asking the community to take care of its
maintenance costs forever. So please, add new code only when it is
really beneficial to the project and to a large audience of
committers and users.
It is like feeding a wild animal at the zoo with chips: everyone
knows it is bad for its health but when you are there it is so nice
when it picks the food from your own hands and you cannot resist and
have to feed it.
OFBiz is now suffering from serious weight issues: the committers
community is having an hard time to maintain the huge codebase, it
is difficult to keep track of all the features in the system etc...
I think it is important to start a new phase of the project and
focus our energy in cleanup and consolidation of what we have. One
step in this direction is for OFBiz to lose weight.
In order to get the ball rolling and focus on some concrete tasks I
am providing here some examples of stuff that I would like to see
removed from the project.
IMPORTANT: Please consider that the list is not based on what I
think the perfect framework should be (so PLEASE do not reply
stating what your ideal framework should have), but simply on the
following considerations:
* can the component be easily removed by the project? is it
independent and can live outside as a plugin?
* do we need all this custom code? can't we find a simpler, lighter
and better way to implement this?
* is this feature used by other code in the system?
* is the feature functional? or is it largely incomplete?
* is this an old component/code?
* is this used by a lot of persons? (this is tricky to decide but
you can get a feeling of it by reading the mailing lists,
considering commit activity, the status of the feature etc...)
DISCLAIMER: I know it will be a painful decision because each of us
reading this will have a connection with some of the code listed
below: several hours spent on it, great ideas that never came to a
finished plan; in fact I feel the same for a few of the things in
the list.... there are great ideas that didn't come to a
finalization... it doesn't mean that moving them out of the project
will kill them and this may actually help to get more visibility and
different user group; so please when you will read it... think to
the greater good of the community.
Legenda for what I propose for each piece of code:
* Attic: remove from code base and document the removal for future
reference in this page
* Extras: identify a person interested in maintaining the code as a
separate project hosted as an Apache Extra project (not officially
under the ASF); add a link to it from the page that will contain
"OFBiz Extras"
And now (drums)..... THE LIST - PART 1(but this is really a very
first pass only, PART 2 will come soon with more granular -
subcomponent - details):
A) move framework/guiapp out of the framework; after all these years
no code made advantage of it being part of the framework and it is
only used by the specialpurpose/pos component (which was the
component for which it was built for); so guiapp can go in the pos
component
B) specialpurpose/pos: move to "Extras"
C) $OFBIZ_HOME/debian: move to "Attic"
D) the seleniumxml code in framework/testtools: move to "Attic"
E) specialpurpose/workflow: move to "Attic"
F) specialpurpose/shark: move to "Attic"
G) specialpurpose/ofbizwebsite: move to "Attic"
H) specialpurpose/*: move several (if not all, apart ecommerce) of
the components to "Extras" (if there are persons interested to
become committers/maintainers) or to "Attic"
I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of
them to "Extras"; keep just one (or two)
J) framework/appserver: move to "Extras"
K) framework/jetty: move to "Extras" (or "Attic")
L) framework/birt (and related dependencies/reports spread around):
move to "Extras"
M) framework/bi (and related dependencies - ecas/business rules and
data - spread around): move to "Extras"
N) framework/jcr: move back into the Jackrabbit branch until the
work is completed and can replace the existing "content framework"
O) framework/documents: move the content to Wiki and then move to "Attic"
P) framework/datafile: (who is currently using it?) move to "Extras"
or "Attic"; we could replace it with commons-csv or similar tool
Q) framework/example and framework/exampleext: move to specialpurpose
Kind regards,
Jacopo
