Hi Jacopo I've worked in organisations where all custom components are split out by function - roughly mirroring the applications components - and also had them lumped in together as you are suggesting, In my experience of this, breaking them out is way easier to maintain and manage even if the are not fully independent of one another. I think the applications component could potentially benefit form common component to address things like BillingAccount that are used across multiple components - but I think that breaking them out could result in one umanageable component.
In an ideal world it would be great to be able to just switch off components. I've worked on projects where I have only really wanted to use the partymgr but because it was so intertwined ended up with close to the the full data model being created as most of the other components had to be loaded as well. Just my thoughts, Rupert On 28 March 2014 09:58, Jacopo Cappellato <[email protected] > wrote: > 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 > > -- Rupert Howell Provolve Ltd Front Office, Deale House, 16 Lavant Street, Petersfield, GU32 3EW, UK t: 01730 267868 / m: 079 0968 5308 e: [email protected] w: http://www.provolve.com
