I think I already mentioned this in the past, and I know it may sound a bad
idea. Also, this is not really a "proposal", just an imperfect idea that needs
to be better defined.
However I think it makes sense to share this with you in order to get some
feedback.
Idea: merge all the "application" components into one ("ofbizerp" or similar).
This component will have all the entity definitions, all service definitions
and their implementations and will also have all the webapps.
The main motivation for this proposal is a reality check, after all these years
of life of the project: it doesn't really make much sense to keep the
application components separated, and it is currently mostly impossible to
deploy a working system with a subset of them.
In fact, even if it is true that there are components that do not depend on
others at compilation time, they mostly all depend on each other at runtime.
For example:
the "accounting" component depends on the "order" component at compilation
time; the "order" component doesn't depend on the "accounting" component at
runtime.
However, the "order" component is independent from the "accounting" component
only if we look at the subset of service implemented in Java; there is no
guarantee, nor best practice, that prevents the "order" component to depend on:
* entities
* services
* Minilang code
* scripts (Groovy etc.)
* data
* other resources (labels, configurations, etc.)
* screens, forms and Freemarker templates
Is this bad design? Maybe not. There are so many entities and services that do
not really belong to a component; for example, the "BillingAccount" entity is
defined in "accounting" but it is widely used by "order" code.
I understand this is a big change, but I feel like it can be done in
incremental steps in the trunk. I also see a big potential for cleaning a lot
of code, removing redundancies and ending up with a simplified architecture
(that may be easier, for example, to deploy to external application containers).
Jacopo
