For the same reasons than Rupert and Ean, I 'm sincerely not a fan of the idea.
Unlike Adrian, I'm not even a fan of merging the framework component
Jacques
Le 28/03/2014 10:58, Jacopo Cappellato a écrit :
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
--
Jacques Le Roux
400E Chemin de la Mouline
34560 Poussan
33+(0)4 67 51 19 38
33+(0)6 11 19 50 28
