I don't see much advantage to merging the components in the
applications folder, but merging components in the framework folder is
sorely needed.
-Adrian
Quoting Jacopo Cappellato <jacopo.cappell...@hotwaxmedia.com>:
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
