You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2014/03/28 10:58:22 UTC
Brainstorming: merging "application" components
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
Re: Brainstorming: merging "application" components
Posted by gavinju <ga...@gmail.com>.
"for example, the "BillingAccount" entity is defined in "accounting" but it
is widely used by "order" code. "
I think the "BillingAccount" entity is defined i "accounting" is
appropriate, it should belongs to the account entity.
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Brainstorming-merging-application-components-tp4649962p4649998.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Brainstorming: merging "application" components
Posted by ad...@sandglass-software.com.
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 <ja...@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
>
>
Re: Brainstorming: merging "application" components
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Re: Brainstorming: merging "application" components
Posted by Rupert Howell <ru...@provolve.com>.
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 <jacopo.cappellato@hotwaxmedia.com
> 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: ruperthowell@provolve.com
w: http://www.provolve.com
Re: Brainstorming: merging "application" components
Posted by Ean Schuessler <ea...@brainfood.com>.
----- "Jacopo Cappellato" <ja...@hotwaxmedia.com> 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.
Quite the contrary I have often wished that there was a way to get a
minimal version of the entity and service engine. I think if we were
judicious in the use of entity inheritance (ie. Party -> Person, etc.)
that we could have a baseline layer that can run with very little code.
Much in the way that JDK8 had to face the modularity demon, I believe
that eventually stacking things together will eventually become a
problem. At some point that baseline will simply become too large and
imply too great a start-up time and utilize too many resources for
many types of projects.
Look also at what Red Hat has done with the start up time of WildFly.
That is inspirational.
--
Ean Schuessler, CTO
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com