Rethinking the structure of the OFBiz Applications Components

[Jacopo Cappellato-4]

In the eraly days of the project, the OFBiz applications have been designed as independent components to make them more reusable and because they were designed to be a set of reusable and generic artifacts, each of them based on a specific domain of the data model (order, party, product etc...).
They were not intended to be ready to be used out of the box; they were not intended to implement complete ERP workflows (mostly all complete real World workflows encompass several domains) but rather to provide some common artifacts (screens, forms, basic business rules) to facilitate the implementation of custom applications.
However over the years, they have been implemented to be used as being part of the same big suite of ERP applications: i.e. the building blocks of a specific instance of an ERP system.
Some (parts) of them have become "ready to be used" out of the box (for certain specific business models) by implementing more specific workflows (based on some real World requirements coming from companies): because of the fact that there was not a central design and coordination (which industry/business to implement etc...) and because for the same task (shipping, receiving etc...) there are thousands of different valid worflows we have now several workflows in OFBiz that implement similar features but in different alternative ways.
It is off topic here to say if this is good (the company user can choose between a series of choices based on the nature of its business and then customize/clean/complete them) or bad (a lot of duplicated code, the applications seem to deal with everything but they are not really really good for anything): however it is a reality that the applications are now more a suite of ERP application (one application) rather than reusable generic artifacts that can be plugged together.
In fact the OFBiz Applications are now a set of OFBiz components that are strictly interdependent at several layers (data model, service, ui).

In their current status I believe that it would be better to merge them into one big component, the "Apache OFBiz ERP" (or a better name).
The component will contain:
* the complete data model for the OFBiz application
* all the services (Java, Minilang)
* all data
* one web application (merged from the existing ones); even if initially we could do this in steps and keep them separated as they are now but under the same component
* one aggregated and consolidated set of ui labels

Even in one component we will have several mechanisms to categorize our artifacts (file names, folders) even if I would suggest to rethink them based on new rules (and only if we need the categorization).
We could merge a lot of files (data preparation scripts, screen definitions, service definitions etc...) to make them more consistent. We would also resolve some of the issues with inter-application links and navigation.
I am pretty sure that we could end up with less code and easier to organize and maintain.

It will also be more practical to reuse this component and extend it from an external hot deploy component: you will have to extend one webapp and then reuse from the official component what you like.

This is just the rough ideas and there could be some variants to it: we could isolate all the data model and services into one component and all the applications (ui, screens, controllers, data prep scripts and templates) into another one. etc. etc. etc...

It is a lot of work but we are a big community and we like to keep us busy.

What do you think?

Jacopo

[Adrian Crum-3]

That approach sounds very monolithic, and I tend to avoid monoliths.

I gave this subject a lot of thought about a year ago when I was working
on a vision for a new framework
(https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision).
In particular, I was trying to devise a way for us to build a new
architecture for OFBiz out of well-defined and self-contained parts -
with the ultimate goal of using OSGI to connect them all together.

That goal led to only one pattern that seemed to work: Hub-and-spoke.
Hubs can be suspended, replaced, and restarted without too much
disruption because they affect only the spokes connected to them.

  It sounds like what you're proposing is a layered pattern - like a
wall built up of many bricks, but with an all-covering capstone on top.

I don't have a strong opinion on which approach is best, but I tend to
favor modularity.

The discussion is worthwhile, and I appreciate you starting it.

-Adrian

On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:

> In the eraly days of the project, the OFBiz applications have been designed as independent components to make them more reusable and because they were designed to be a set of reusable and generic artifacts, each of them based on a specific domain of the data model (order, party, product etc...).
> They were not intended to be ready to be used out of the box; they were not intended to implement complete ERP workflows (mostly all complete real World workflows encompass several domains) but rather to provide some common artifacts (screens, forms, basic business rules) to facilitate the implementation of custom applications.
> However over the years, they have been implemented to be used as being part of the same big suite of ERP applications: i.e. the building blocks of a specific instance of an ERP system.
> Some (parts) of them have become "ready to be used" out of the box (for certain specific business models) by implementing more specific workflows (based on some real World requirements coming from companies): because of the fact that there was not a central design and coordination (which industry/business to implement etc...) and because for the same task (shipping, receiving etc...) there are thousands of different valid worflows we have now several workflows in OFBiz that implement similar features but in different alternative ways.
> It is off topic here to say if this is good (the company user can choose between a series of choices based on the nature of its business and then customize/clean/complete them) or bad (a lot of duplicated code, the applications seem to deal with everything but they are not really really good for anything): however it is a reality that the applications are now more a suite of ERP application (one application) rather than reusable generic artifacts that can be plugged together.
> In fact the OFBiz Applications are now a set of OFBiz components that are strictly interdependent at several layers (data model, service, ui).
>
> In their current status I believe that it would be better to merge them into one big component, the "Apache OFBiz ERP" (or a better name).
> The component will contain:
> * the complete data model for the OFBiz application
> * all the services (Java, Minilang)
> * all data
> * one web application (merged from the existing ones); even if initially we could do this in steps and keep them separated as they are now but under the same component
> * one aggregated and consolidated set of ui labels
>
> Even in one component we will have several mechanisms to categorize our artifacts (file names, folders) even if I would suggest to rethink them based on new rules (and only if we need the categorization).
> We could merge a lot of files (data preparation scripts, screen definitions, service definitions etc...) to make them more consistent. We would also resolve some of the issues with inter-application links and navigation.
> I am pretty sure that we could end up with less code and easier to organize and maintain.
>
> It will also be more practical to reuse this component and extend it from an external hot deploy component: you will have to extend one webapp and then reuse from the official component what you like.
>
> This is just the rough ideas and there could be some variants to it: we could isolate all the data model and services into one component and all the applications (ui, screens, controllers, data prep scripts and templates) into another one. etc. etc. etc...
>
> It is a lot of work but we are a big community and we like to keep us busy.
>
> What do you think?
>
> Jacopo
>

[Jacopo Cappellato-4]

Thank you Adrian.

Just to clarify that I was not talking about the architecture of the framework (topic for another day) but only for the layout of the applications and it is not based on what I think it is best in general but instead about what I think it is best to represent what we have right now: what we have right now is *one* big application (made of mostly all the components under the "applications" folder) that is split into chunks (the components) where each chunk is not built to be used alone.
I would be really interested to know from the users of the "applications" how many of them are removing (or not deploying) the components they do not need in their business.

All in all I am trying to better represent (in a more convenient, cheaper, easier to maintain way) what we already have, not to suggest how the perfect application built on OFBiz should be. The approach that you are suggesting on the other hand, that is inspiring, implies a complete refactoring and redesign (also in terms of features) of the applications.

Jacopo

On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:

> That approach sounds very monolithic, and I tend to avoid monoliths.
>
> I gave this subject a lot of thought about a year ago when I was working on a vision for a new framework (https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision). In particular, I was trying to devise a way for us to build a new architecture for OFBiz out of well-defined and self-contained parts - with the ultimate goal of using OSGI to connect them all together.
>
> That goal led to only one pattern that seemed to work: Hub-and-spoke. Hubs can be suspended, replaced, and restarted without too much disruption because they affect only the spokes connected to them.
>
> It sounds like what you're proposing is a layered pattern - like a wall built up of many bricks, but with an all-covering capstone on top.
>
> I don't have a strong opinion on which approach is best, but I tend to favor modularity.
>
> The discussion is worthwhile, and I appreciate you starting it.
>
> -Adrian
>
> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>> In the eraly days of the project, the OFBiz applications have been designed as independent components to make them more reusable and because they were designed to be a set of reusable and generic artifacts, each of them based on a specific domain of the data model (order, party, product etc...).
>> They were not intended to be ready to be used out of the box; they were not intended to implement complete ERP workflows (mostly all complete real World workflows encompass several domains) but rather to provide some common artifacts (screens, forms, basic business rules) to facilitate the implementation of custom applications.
>> However over the years, they have been implemented to be used as being part of the same big suite of ERP applications: i.e. the building blocks of a specific instance of an ERP system.
>> Some (parts) of them have become "ready to be used" out of the box (for certain specific business models) by implementing more specific workflows (based on some real World requirements coming from companies): because of the fact that there was not a central design and coordination (which industry/business to implement etc...) and because for the same task (shipping, receiving etc...) there are thousands of different valid worflows we have now several workflows in OFBiz that implement similar features but in different alternative ways.
>> It is off topic here to say if this is good (the company user can choose between a series of choices based on the nature of its business and then customize/clean/complete them) or bad (a lot of duplicated code, the applications seem to deal with everything but they are not really really good for anything): however it is a reality that the applications are now more a suite of ERP application (one application) rather than reusable generic artifacts that can be plugged together.
>> In fact the OFBiz Applications are now a set of OFBiz components that are strictly interdependent at several layers (data model, service, ui).
>>
>> In their current status I believe that it would be better to merge them into one big component, the "Apache OFBiz ERP" (or a better name).
>> The component will contain:
>> * the complete data model for the OFBiz application
>> * all the services (Java, Minilang)
>> * all data
>> * one web application (merged from the existing ones); even if initially we could do this in steps and keep them separated as they are now but under the same component
>> * one aggregated and consolidated set of ui labels
>>
>> Even in one component we will have several mechanisms to categorize our artifacts (file names, folders) even if I would suggest to rethink them based on new rules (and only if we need the categorization).
>> We could merge a lot of files (data preparation scripts, screen definitions, service definitions etc...) to make them more consistent. We would also resolve some of the issues with inter-application links and navigation.
>> I am pretty sure that we could end up with less code and easier to organize and maintain.
>>
>> It will also be more practical to reuse this component and extend it from an external hot deploy component: you will have to extend one webapp and then reuse from the official component what you like.
>>
>> This is just the rough ideas and there could be some variants to it: we could isolate all the data model and services into one component and all the applications (ui, screens, controllers, data prep scripts and templates) into another one. etc. etc. etc...
>>
>> It is a lot of work but we are a big community and we like to keep us busy.
>>
>> What do you think?
>>
>> Jacopo
>>

[Adrian Crum-3]

Understood.

As a service provider, I regularly comment out unused applications and
build hot-deploy components to replace OOTB OFBiz components. I override
service definitions, redefine entity definitions, etc - all in an effort
to take what's good in OFBiz, and replace what's not-so-good. I seem to
be doing a lot more of it lately - mostly due to components being added
that break every other component. At least with a component approach,
that sort of thing can be isolated and dealt with.

-Adrian

On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:

> Thank you Adrian.
>
> Just to clarify that I was not talking about the architecture of the framework (topic for another day) but only for the layout of the applications and it is not based on what I think it is best in general but instead about what I think it is best to represent what we have right now: what we have right now is *one* big application (made of mostly all the components under the "applications" folder) that is split into chunks (the components) where each chunk is not built to be used alone.
> I would be really interested to know from the users of the "applications" how many of them are removing (or not deploying) the components they do not need in their business.
>
> All in all I am trying to better represent (in a more convenient, cheaper, easier to maintain way) what we already have, not to suggest how the perfect application built on OFBiz should be. The approach that you are suggesting on the other hand, that is inspiring, implies a complete refactoring and redesign (also in terms of features) of the applications.
>
> Jacopo
>
> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>
>> That approach sounds very monolithic, and I tend to avoid monoliths.
>>
>> I gave this subject a lot of thought about a year ago when I was working on a vision for a new framework (https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision). In particular, I was trying to devise a way for us to build a new architecture for OFBiz out of well-defined and self-contained parts - with the ultimate goal of using OSGI to connect them all together.
>>
>> That goal led to only one pattern that seemed to work: Hub-and-spoke. Hubs can be suspended, replaced, and restarted without too much disruption because they affect only the spokes connected to them.
>>
>> It sounds like what you're proposing is a layered pattern - like a wall built up of many bricks, but with an all-covering capstone on top.
>>
>> I don't have a strong opinion on which approach is best, but I tend to favor modularity.
>>
>> The discussion is worthwhile, and I appreciate you starting it.
>>
>> -Adrian
>>
>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>> In the eraly days of the project, the OFBiz applications have been designed as independent components to make them more reusable and because they were designed to be a set of reusable and generic artifacts, each of them based on a specific domain of the data model (order, party, product etc...).
>>> They were not intended to be ready to be used out of the box; they were not intended to implement complete ERP workflows (mostly all complete real World workflows encompass several domains) but rather to provide some common artifacts (screens, forms, basic business rules) to facilitate the implementation of custom applications.
>>> However over the years, they have been implemented to be used as being part of the same big suite of ERP applications: i.e. the building blocks of a specific instance of an ERP system.
>>> Some (parts) of them have become "ready to be used" out of the box (for certain specific business models) by implementing more specific workflows (based on some real World requirements coming from companies): because of the fact that there was not a central design and coordination (which industry/business to implement etc...) and because for the same task (shipping, receiving etc...) there are thousands of different valid worflows we have now several workflows in OFBiz that implement similar features but in different alternative ways.
>>> It is off topic here to say if this is good (the company user can choose between a series of choices based on the nature of its business and then customize/clean/complete them) or bad (a lot of duplicated code, the applications seem to deal with everything but they are not really really good for anything): however it is a reality that the applications are now more a suite of ERP application (one application) rather than reusable generic artifacts that can be plugged together.
>>> In fact the OFBiz Applications are now a set of OFBiz components that are strictly interdependent at several layers (data model, service, ui).
>>>
>>> In their current status I believe that it would be better to merge them into one big component, the "Apache OFBiz ERP" (or a better name).
>>> The component will contain:
>>> * the complete data model for the OFBiz application
>>> * all the services (Java, Minilang)
>>> * all data
>>> * one web application (merged from the existing ones); even if initially we could do this in steps and keep them separated as they are now but under the same component
>>> * one aggregated and consolidated set of ui labels
>>>
>>> Even in one component we will have several mechanisms to categorize our artifacts (file names, folders) even if I would suggest to rethink them based on new rules (and only if we need the categorization).
>>> We could merge a lot of files (data preparation scripts, screen definitions, service definitions etc...) to make them more consistent. We would also resolve some of the issues with inter-application links and navigation.
>>> I am pretty sure that we could end up with less code and easier to organize and maintain.
>>>
>>> It will also be more practical to reuse this component and extend it from an external hot deploy component: you will have to extend one webapp and then reuse from the official component what you like.
>>>
>>> This is just the rough ideas and there could be some variants to it: we could isolate all the data model and services into one component and all the applications (ui, screens, controllers, data prep scripts and templates) into another one. etc. etc. etc...
>>>
>>> It is a lot of work but we are a big community and we like to keep us busy.
>>>
>>> What do you think?
>>>
>>> Jacopo
>>>

[Jacopo Cappellato-4]

On Mar 14, 2012, at 6:33 PM, Adrian Crum wrote:

> Understood.
>
> As a service provider, I regularly comment out unused applications

I would be interested to know what are the applications under the "applications" folder that you comment out: do you you mean web applications, not component

> and build hot-deploy components to replace OOTB OFBiz components.

we (the company I work for) do the same extensively

> I override service definitions, redefine entity definitions, etc - all in an effort to take what's good in OFBiz, and replace what's not-so-good

we do the same; to take the good and also to add custom features not well suited for the general purpose applications


> . I seem to be doing a lot more of it lately

This is the approach we follow since a long time and it has proven to be effective.

> - mostly due to components being added that break every other component.

this is another sad topic :-)

> At least with a component approach, that sort of thing can be isolated and dealt with.

I don't see how the tasks mentioned above are easier with the applications split into components.

Jacopo

>
> -Adrian
>
> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
>> Thank you Adrian.
>>
>> Just to clarify that I was not talking about the architecture of the framework (topic for another day) but only for the layout of the applications and it is not based on what I think it is best in general but instead about what I think it is best to represent what we have right now: what we have right now is *one* big application (made of mostly all the components under the "applications" folder) that is split into chunks (the components) where each chunk is not built to be used alone.
>> I would be really interested to know from the users of the "applications" how many of them are removing (or not deploying) the components they do not need in their business.
>>
>> All in all I am trying to better represent (in a more convenient, cheaper, easier to maintain way) what we already have, not to suggest how the perfect application built on OFBiz should be. The approach that you are suggesting on the other hand, that is inspiring, implies a complete refactoring and redesign (also in terms of features) of the applications.
>>
>> Jacopo
>>
>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>>
>>> That approach sounds very monolithic, and I tend to avoid monoliths.
>>>
>>> I gave this subject a lot of thought about a year ago when I was working on a vision for a new framework (https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision). In particular, I was trying to devise a way for us to build a new architecture for OFBiz out of well-defined and self-contained parts - with the ultimate goal of using OSGI to connect them all together.
>>>
>>> That goal led to only one pattern that seemed to work: Hub-and-spoke. Hubs can be suspended, replaced, and restarted without too much disruption because they affect only the spokes connected to them.
>>>
>>> It sounds like what you're proposing is a layered pattern - like a wall built up of many bricks, but with an all-covering capstone on top.
>>>
>>> I don't have a strong opinion on which approach is best, but I tend to favor modularity.
>>>
>>> The discussion is worthwhile, and I appreciate you starting it.
>>>
>>> -Adrian
>>>
>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>>> In the eraly days of the project, the OFBiz applications have been designed as independent components to make them more reusable and because they were designed to be a set of reusable and generic artifacts, each of them based on a specific domain of the data model (order, party, product etc...).
>>>> They were not intended to be ready to be used out of the box; they were not intended to implement complete ERP workflows (mostly all complete real World workflows encompass several domains) but rather to provide some common artifacts (screens, forms, basic business rules) to facilitate the implementation of custom applications.
>>>> However over the years, they have been implemented to be used as being part of the same big suite of ERP applications: i.e. the building blocks of a specific instance of an ERP system.
>>>> Some (parts) of them have become "ready to be used" out of the box (for certain specific business models) by implementing more specific workflows (based on some real World requirements coming from companies): because of the fact that there was not a central design and coordination (which industry/business to implement etc...) and because for the same task (shipping, receiving etc...) there are thousands of different valid worflows we have now several workflows in OFBiz that implement similar features but in different alternative ways.
>>>> It is off topic here to say if this is good (the company user can choose between a series of choices based on the nature of its business and then customize/clean/complete them) or bad (a lot of duplicated code, the applications seem to deal with everything but they are not really really good for anything): however it is a reality that the applications are now more a suite of ERP application (one application) rather than reusable generic artifacts that can be plugged together.
>>>> In fact the OFBiz Applications are now a set of OFBiz components that are strictly interdependent at several layers (data model, service, ui).
>>>>
>>>> In their current status I believe that it would be better to merge them into one big component, the "Apache OFBiz ERP" (or a better name).
>>>> The component will contain:
>>>> * the complete data model for the OFBiz application
>>>> * all the services (Java, Minilang)
>>>> * all data
>>>> * one web application (merged from the existing ones); even if initially we could do this in steps and keep them separated as they are now but under the same component
>>>> * one aggregated and consolidated set of ui labels
>>>>
>>>> Even in one component we will have several mechanisms to categorize our artifacts (file names, folders) even if I would suggest to rethink them based on new rules (and only if we need the categorization).
>>>> We could merge a lot of files (data preparation scripts, screen definitions, service definitions etc...) to make them more consistent. We would also resolve some of the issues with inter-application links and navigation.
>>>> I am pretty sure that we could end up with less code and easier to organize and maintain.
>>>>
>>>> It will also be more practical to reuse this component and extend it from an external hot deploy component: you will have to extend one webapp and then reuse from the official component what you like.
>>>>
>>>> This is just the rough ideas and there could be some variants to it: we could isolate all the data model and services into one component and all the applications (ui, screens, controllers, data prep scripts and templates) into another one. etc. etc. etc...
>>>>
>>>> It is a lot of work but we are a big community and we like to keep us busy.
>>>>
>>>> What do you think?
>>>>
>>>> Jacopo
>>>>

[Pierre Smits]

Hi Adrian,

Could you list the applications you comment out in your production
implementations? I think that would help creating insight.

Regards,

Pierre

Op 14 maart 2012 18:33 schreef Adrian Crum <
[hidden email]> het volgende:

> Understood.
>
> As a service provider, I regularly comment out unused applications and
> build hot-deploy components to replace OOTB OFBiz components. I override
> service definitions, redefine entity definitions, etc - all in an effort to
> take what's good in OFBiz, and replace what's not-so-good. I seem to be
> doing a lot more of it lately - mostly due to components being added that
> break every other component. At least with a component approach, that sort
> of thing can be isolated and dealt with.
>
> -Adrian
>
>
> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
>
>> Thank you Adrian.
>>
>> Just to clarify that I was not talking about the architecture of the
>> framework (topic for another day) but only for the layout of the
>> applications and it is not based on what I think it is best in general but
>> instead about what I think it is best to represent what we have right now:
>> what we have right now is *one* big application (made of mostly all the
>> components under the "applications" folder) that is split into chunks (the
>> components) where each chunk is not built to be used alone.
>> I would be really interested to know from the users of the "applications"
>> how many of them are removing (or not deploying) the components they do not
>> need in their business.
>>
>> All in all I am trying to better represent (in a more convenient,
>> cheaper, easier to maintain way) what we already have, not to suggest how
>> the perfect application built on OFBiz should be. The approach that you are
>> suggesting on the other hand, that is inspiring, implies a complete
>> refactoring and redesign (also in terms of features) of the applications.
>>
>> Jacopo
>>
>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>>
>>  That approach sounds very monolithic, and I tend to avoid monoliths.
>>>
>>> I gave this subject a lot of thought about a year ago when I was working
>>> on a vision for a new framework (https://cwiki.apache.org/**
>>> confluence/display/OFBADMIN/**Another+Framework+Vision<https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision>).
>>> In particular, I was trying to devise a way for us to build a new
>>> architecture for OFBiz out of well-defined and self-contained parts - with
>>> the ultimate goal of using OSGI to connect them all together.
>>>
>>> That goal led to only one pattern that seemed to work: Hub-and-spoke.
>>> Hubs can be suspended, replaced, and restarted without too much disruption
>>> because they affect only the spokes connected to them.
>>>
>>> It sounds like what you're proposing is a layered pattern - like a wall
>>> built up of many bricks, but with an all-covering capstone on top.
>>>
>>> I don't have a strong opinion on which approach is best, but I tend to
>>> favor modularity.
>>>
>>> The discussion is worthwhile, and I appreciate you starting it.
>>>
>>> -Adrian
>>>
>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>>
>>>> In the eraly days of the project, the OFBiz applications have been
>>>> designed as independent components to make them more reusable and because
>>>> they were designed to be a set of reusable and generic artifacts, each of
>>>> them based on a specific domain of the data model (order, party, product
>>>> etc...).
>>>> They were not intended to be ready to be used out of the box; they were
>>>> not intended to implement complete ERP workflows (mostly all complete real
>>>> World workflows encompass several domains) but rather to provide some
>>>> common artifacts (screens, forms, basic business rules) to facilitate the
>>>> implementation of custom applications.
>>>> However over the years, they have been implemented to be used as being
>>>> part of the same big suite of ERP applications: i.e. the building blocks of
>>>> a specific instance of an ERP system.
>>>> Some (parts) of them have become "ready to be used" out of the box (for
>>>> certain specific business models) by implementing more specific workflows
>>>> (based on some real World requirements coming from companies): because of
>>>> the fact that there was not a central design and coordination (which
>>>> industry/business to implement etc...) and because for the same task
>>>> (shipping, receiving etc...) there are thousands of different valid
>>>> worflows we have now several workflows in OFBiz that implement similar
>>>> features but in different alternative ways.
>>>> It is off topic here to say if this is good (the company user can
>>>> choose between a series of choices based on the nature of its business and
>>>> then customize/clean/complete them) or bad (a lot of duplicated code, the
>>>> applications seem to deal with everything but they are not really really
>>>> good for anything): however it is a reality that the applications are now
>>>> more a suite of ERP application (one application) rather than reusable
>>>> generic artifacts that can be plugged together.
>>>> In fact the OFBiz Applications are now a set of OFBiz components that
>>>> are strictly interdependent at several layers (data model, service, ui).
>>>>
>>>> In their current status I believe that it would be better to merge them
>>>> into one big component, the "Apache OFBiz ERP" (or a better name).
>>>> The component will contain:
>>>> * the complete data model for the OFBiz application
>>>> * all the services (Java, Minilang)
>>>> * all data
>>>> * one web application (merged from the existing ones); even if
>>>> initially we could do this in steps and keep them separated as they are now
>>>> but under the same component
>>>> * one aggregated and consolidated set of ui labels
>>>>
>>>> Even in one component we will have several mechanisms to categorize our
>>>> artifacts (file names, folders) even if I would suggest to rethink them
>>>> based on new rules (and only if we need the categorization).
>>>> We could merge a lot of files (data preparation scripts, screen
>>>> definitions, service definitions etc...) to make them more consistent. We
>>>> would also resolve some of the issues with inter-application links and
>>>> navigation.
>>>> I am pretty sure that we could end up with less code and easier to
>>>> organize and maintain.
>>>>
>>>> It will also be more practical to reuse this component and extend it
>>>> from an external hot deploy component: you will have to extend one webapp
>>>> and then reuse from the official component what you like.
>>>>
>>>> This is just the rough ideas and there could be some variants to it: we
>>>> could isolate all the data model and services into one component and all
>>>> the applications (ui, screens, controllers, data prep scripts and
>>>> templates) into another one. etc. etc. etc...
>>>>
>>>> It is a lot of work but we are a big community and we like to keep us
>>>> busy.
>>>>
>>>> What do you think?
>>>>
>>>> Jacopo
>>>>
>>>>

[Tom]

Adrian / Jacopo

While thinking about a refactoring the OFBiz Architecture you
may want to look at http://www.aosabook.org/en/intro.html. The book is all
about Open Source architecture. In particular see the chapter on Eclipse, the
ultimate open source component framework, Eclipse is the perfect environment to
implement Adrian's ambitious vision.
 
However the most pressing problem in OFBiz, given the
available resources, is not the architecture, rearranging the components or refactoring
of what in Moque would be the Core / Mantel (i.e. a scripting framework etc.).
 
Rather the problem, as your most recent post to this thread
suggest, is the short comings in the OFBiz Crust. OOB the user facing
applications are difficult to understand, quirky and do not support needed business
requirements. Just ask yourself would you go into a meeting with Steve Jobs ghost
with these applications?
 
On the OFBiz home page "What is Apache OFBiz" the
focus is clearly ERP. The bullet points advertise OOB application
functionality. The business applications should be easy to use, robust, and well
documented. This will require more attention to business requirements,
providing a consistent set of defined services, adherence to documented UI best
practices and well written and better presented user help.
 
All of this is possible without doing more additional work
on the Core / Mantel.
 
I would be happy to contribute to an effort to improve the
user facing applications if there is support from the committers.
 
I see these applications as falling into two categories. Applications
that are common to most businesses and domain specific applications. This
follows the pattern laid out in the two DMR Books. The former, more general,
category should get the most attention. Those applications include:
Common Business - Requirements common to most businesses
 Accounting
 Human Resources
 Marketing
 Work Effort
 Reporting
 Document Management
 E-Commerce
 Others to be
identified
 I would like to start with Human Resources. Is anyone interested?

Tom



________________________________
 From: Pierre Smits <[hidden email]>
To: [hidden email]
Sent: Wednesday, March 14, 2012 5:53 PM
Subject: Re: Rethinking the structure of the OFBiz Applications Components
 
Hi Adrian,

Could you list the applications you comment out in your production
implementations? I think that would help creating insight.

Regards,

Pierre

Op 14 maart 2012 18:33 schreef Adrian Crum <
[hidden email]> het volgende:

> Understood.
>
> As a service provider, I regularly comment out unused applications and
> build hot-deploy components to replace OOTB OFBiz components. I override
> service definitions, redefine entity definitions, etc - all in an effort to
> take what's good in OFBiz, and replace what's not-so-good. I seem to be
> doing a lot more of it lately - mostly due to components being added that
> break every other component. At least with a component approach, that sort
> of thing can be isolated and dealt with.
>
> -Adrian
>
>
> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
>
>> Thank you Adrian.
>>
>> Just to clarify that I was not talking about the architecture of the
>> framework (topic for another day) but only for the layout of the
>> applications and it is not based on what I think it is best in general but
>> instead about what I think it is best to represent what we have right now:
>> what we have right now is *one* big application (made of mostly all the
>> components under the "applications" folder) that is split into chunks (the
>> components) where each chunk is not built to be used alone.
>> I would be really interested to know from the users of the "applications"
>> how many of them are removing (or not deploying) the components they do not
>> need in their business.
>>
>> All in all I am trying to better represent (in a more convenient,
>> cheaper, easier to maintain way) what we already have, not to suggest how
>> the perfect application built on OFBiz should be. The approach that you are
>> suggesting on the other hand, that is inspiring, implies a complete
>> refactoring and redesign (also in terms of features) of the applications.
>>
>> Jacopo
>>
>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>>
>>  That approach sounds very monolithic, and I tend to avoid monoliths.
>>>
>>> I gave this subject a lot of thought about a year ago when I was working
>>> on a vision for a new framework (https://cwiki.apache.org/**
>>> confluence/display/OFBADMIN/**Another+Framework+Vision<https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision>).
>>> In particular, I was trying to devise a way for us to build a new
>>> architecture for OFBiz out of well-defined and self-contained parts - with
>>> the ultimate goal of using OSGI to connect them all together.
>>>
>>> That goal led to only one pattern that seemed to work: Hub-and-spoke.
>>> Hubs can be suspended, replaced, and restarted without too much disruption
>>> because they affect only the spokes connected to them.
>>>
>>> It sounds like what you're proposing is a layered pattern - like a wall
>>> built up of many bricks, but with an all-covering capstone on top.
>>>
>>> I don't have a strong opinion on which approach is best, but I tend to
>>> favor modularity.
>>>
>>> The discussion is worthwhile, and I appreciate you starting it.
>>>
>>> -Adrian
>>>
>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>>
>>>> In the eraly days of the project, the OFBiz applications have been
>>>> designed as independent components to make them more reusable and because
>>>> they were designed to be a set of reusable and generic artifacts, each of
>>>> them based on a specific domain of the data model (order, party, product
>>>> etc...).
>>>> They were not intended to be ready to be used out of the box; they were
>>>> not intended to implement complete ERP workflows (mostly all complete real
>>>> World workflows encompass several domains) but rather to provide some
>>>> common artifacts (screens, forms, basic business rules) to facilitate the
>>>> implementation of custom applications.
>>>> However over the years, they have been implemented to be used as being
>>>> part of the same big suite of ERP applications: i.e. the building blocks of
>>>> a specific instance of an ERP system.
>>>> Some (parts) of them have become "ready to be used" out of the box (for
>>>> certain specific business models) by implementing more specific workflows
>>>> (based on some real World requirements coming from companies): because of
>>>> the fact that there was not a central design and coordination (which
>>>> industry/business to implement etc...) and because for the same task
>>>> (shipping, receiving etc...) there are thousands of different valid
>>>> worflows we have now several workflows in OFBiz that implement similar
>>>> features but in different alternative ways.
>>>> It is off topic here to say if this is good (the company user can
>>>> choose between a series of choices based on the nature of its business and
>>>> then customize/clean/complete them) or bad (a lot of duplicated code, the
>>>> applications seem to deal with everything but they are not really really
>>>> good for anything): however it is a reality that the applications are now
>>>> more a suite of ERP application (one application) rather than reusable
>>>> generic artifacts that can be plugged together.
>>>> In fact the OFBiz Applications are now a set of OFBiz components that
>>>> are strictly interdependent at several layers (data model, service, ui).
>>>>
>>>> In their current status I believe that it would be better to merge them
>>>> into one big component, the "Apache OFBiz ERP" (or a better name).
>>>> The component will contain:
>>>> * the complete data model for the OFBiz application
>>>> * all the services (Java, Minilang)
>>>> * all data
>>>> * one web application (merged from the existing ones); even if
>>>> initially we could do this in steps and keep them separated as they are now
>>>> but under the same component
>>>> * one aggregated and consolidated set of ui labels
>>>>
>>>> Even in one component we will have several mechanisms to categorize our
>>>> artifacts (file names, folders) even if I would suggest to rethink them
>>>> based on new rules (and only if we need the categorization).
>>>> We could merge a lot of files (data preparation scripts, screen
>>>> definitions, service definitions etc...) to make them more consistent. We
>>>> would also resolve some of the issues with inter-application links and
>>>> navigation.
>>>> I am pretty sure that we could end up with less code and easier to
>>>> organize and maintain.
>>>>
>>>> It will also be more practical to reuse this component and extend it
>>>> from an external hot deploy component: you will have to extend one webapp
>>>> and then reuse from the official component what you like.
>>>>
>>>> This is just the rough ideas and there could be some variants to it: we
>>>> could isolate all the data model and services into one component and all
>>>> the applications (ui, screens, controllers, data prep scripts and
>>>> templates) into another one. etc. etc. etc...
>>>>
>>>> It is a lot of work but we are a big community and we like to keep us
>>>> busy.
>>>>
>>>> What do you think?
>>>>
>>>> Jacopo
>>>>
>>>>

[hongs bill]

+1

2012/3/15 Tom Burns <[hidden email]>

> Adrian / Jacopo
>
> While thinking about a refactoring the OFBiz Architecture you
> may want to look at http://www.aosabook.org/en/intro.html. The book is all
> about Open Source architecture. In particular see the chapter on Eclipse,
> the
> ultimate open source component framework, Eclipse is the perfect
> environment to
> implement Adrian's ambitious vision.
>
> However the most pressing problem in OFBiz, given the
> available resources, is not the architecture, rearranging the components
> or refactoring
> of what in Moque would be the Core / Mantel (i.e. a scripting framework
> etc.).
>
> Rather the problem, as your most recent post to this thread
> suggest, is the short comings in the OFBiz Crust. OOB the user facing
> applications are difficult to understand, quirky and do not support needed
> business
> requirements. Just ask yourself would you go into a meeting with Steve
> Jobs ghost
> with these applications?
>
> On the OFBiz home page "What is Apache OFBiz" the
> focus is clearly ERP. The bullet points advertise OOB application
> functionality. The business applications should be easy to use, robust,
> and well
> documented. This will require more attention to business requirements,
> providing a consistent set of defined services, adherence to documented UI
> best
> practices and well written and better presented user help.
>
> All of this is possible without doing more additional work
> on the Core / Mantel.
>
> I would be happy to contribute to an effort to improve the
> user facing applications if there is support from the committers.
>
> I see these applications as falling into two categories. Applications
> that are common to most businesses and domain specific applications. This
> follows the pattern laid out in the two DMR Books. The former, more
> general,
> category should get the most attention. Those applications include:
> Common Business - Requirements common to most businesses
>  Accounting
>  Human Resources
>  Marketing
>  Work Effort
>  Reporting
>  Document Management
>  E-Commerce
>  Others to be
> identified
>  I would like to start with Human Resources. Is anyone interested?
>
> Tom
>
>
>
> ________________________________
>  From: Pierre Smits <[hidden email]>
> To: [hidden email]
> Sent: Wednesday, March 14, 2012 5:53 PM
> Subject: Re: Rethinking the structure of the OFBiz Applications Components
>
> Hi Adrian,
>
> Could you list the applications you comment out in your production
> implementations? I think that would help creating insight.
>
> Regards,
>
> Pierre
>
> Op 14 maart 2012 18:33 schreef Adrian Crum <
> [hidden email]> het volgende:
>
> > Understood.
> >
> > As a service provider, I regularly comment out unused applications and
> > build hot-deploy components to replace OOTB OFBiz components. I override
> > service definitions, redefine entity definitions, etc - all in an effort
> to
> > take what's good in OFBiz, and replace what's not-so-good. I seem to be
> > doing a lot more of it lately - mostly due to components being added that
> > break every other component. At least with a component approach, that
> sort
> > of thing can be isolated and dealt with.
> >
> > -Adrian
> >
> >
> > On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
> >
> >> Thank you Adrian.
> >>
> >> Just to clarify that I was not talking about the architecture of the
> >> framework (topic for another day) but only for the layout of the
> >> applications and it is not based on what I think it is best in general
> but
> >> instead about what I think it is best to represent what we have right
> now:
> >> what we have right now is *one* big application (made of mostly all the
> >> components under the "applications" folder) that is split into chunks
> (the
> >> components) where each chunk is not built to be used alone.
> >> I would be really interested to know from the users of the
> "applications"
> >> how many of them are removing (or not deploying) the components they do
> not
> >> need in their business.
> >>
> >> All in all I am trying to better represent (in a more convenient,
> >> cheaper, easier to maintain way) what we already have, not to suggest
> how
> >> the perfect application built on OFBiz should be. The approach that you
> are
> >> suggesting on the other hand, that is inspiring, implies a complete
> >> refactoring and redesign (also in terms of features) of the
> applications.
> >>
> >> Jacopo
> >>
> >> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
> >>
> >>  That approach sounds very monolithic, and I tend to avoid monoliths.
> >>>
> >>> I gave this subject a lot of thought about a year ago when I was
> working
> >>> on a vision for a new framework (https://cwiki.apache.org/**
> >>> confluence/display/OFBADMIN/**Another+Framework+Vision<
> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
> >).
> >>> In particular, I was trying to devise a way for us to build a new
> >>> architecture for OFBiz out of well-defined and self-contained parts -
> with
> >>> the ultimate goal of using OSGI to connect them all together.
> >>>
> >>> That goal led to only one pattern that seemed to work: Hub-and-spoke.
> >>> Hubs can be suspended, replaced, and restarted without too much
> disruption
> >>> because they affect only the spokes connected to them.
> >>>
> >>> It sounds like what you're proposing is a layered pattern - like a wall
> >>> built up of many bricks, but with an all-covering capstone on top.
> >>>
> >>> I don't have a strong opinion on which approach is best, but I tend to
> >>> favor modularity.
> >>>
> >>> The discussion is worthwhile, and I appreciate you starting it.
> >>>
> >>> -Adrian
> >>>
> >>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
> >>>
> >>>> In the eraly days of the project, the OFBiz applications have been
> >>>> designed as independent components to make them more reusable and
> because
> >>>> they were designed to be a set of reusable and generic artifacts,
> each of
> >>>> them based on a specific domain of the data model (order, party,
> product
> >>>> etc...).
> >>>> They were not intended to be ready to be used out of the box; they
> were
> >>>> not intended to implement complete ERP workflows (mostly all complete
> real
> >>>> World workflows encompass several domains) but rather to provide some
> >>>> common artifacts (screens, forms, basic business rules) to facilitate
> the
> >>>> implementation of custom applications.
> >>>> However over the years, they have been implemented to be used as being
> >>>> part of the same big suite of ERP applications: i.e. the building
> blocks of
> >>>> a specific instance of an ERP system.
> >>>> Some (parts) of them have become "ready to be used" out of the box
> (for
> >>>> certain specific business models) by implementing more specific
> workflows
> >>>> (based on some real World requirements coming from companies):
> because of
> >>>> the fact that there was not a central design and coordination (which
> >>>> industry/business to implement etc...) and because for the same task
> >>>> (shipping, receiving etc...) there are thousands of different valid
> >>>> worflows we have now several workflows in OFBiz that implement similar
> >>>> features but in different alternative ways.
> >>>> It is off topic here to say if this is good (the company user can
> >>>> choose between a series of choices based on the nature of its
> business and
> >>>> then customize/clean/complete them) or bad (a lot of duplicated code,
> the
> >>>> applications seem to deal with everything but they are not really
> really
> >>>> good for anything): however it is a reality that the applications are
> now
> >>>> more a suite of ERP application (one application) rather than reusable
> >>>> generic artifacts that can be plugged together.
> >>>> In fact the OFBiz Applications are now a set of OFBiz components that
> >>>> are strictly interdependent at several layers (data model, service,
> ui).
> >>>>
> >>>> In their current status I believe that it would be better to merge
> them
> >>>> into one big component, the "Apache OFBiz ERP" (or a better name).
> >>>> The component will contain:
> >>>> * the complete data model for the OFBiz application
> >>>> * all the services (Java, Minilang)
> >>>> * all data
> >>>> * one web application (merged from the existing ones); even if
> >>>> initially we could do this in steps and keep them separated as they
> are now
> >>>> but under the same component
> >>>> * one aggregated and consolidated set of ui labels
> >>>>
> >>>> Even in one component we will have several mechanisms to categorize
> our
> >>>> artifacts (file names, folders) even if I would suggest to rethink
> them
> >>>> based on new rules (and only if we need the categorization).
> >>>> We could merge a lot of files (data preparation scripts, screen
> >>>> definitions, service definitions etc...) to make them more
> consistent. We
> >>>> would also resolve some of the issues with inter-application links and
> >>>> navigation.
> >>>> I am pretty sure that we could end up with less code and easier to
> >>>> organize and maintain.
> >>>>
> >>>> It will also be more practical to reuse this component and extend it
> >>>> from an external hot deploy component: you will have to extend one
> webapp
> >>>> and then reuse from the official component what you like.
> >>>>
> >>>> This is just the rough ideas and there could be some variants to it:
> we
> >>>> could isolate all the data model and services into one component and
> all
> >>>> the applications (ui, screens, controllers, data prep scripts and
> >>>> templates) into another one. etc. etc. etc...
> >>>>
> >>>> It is a lot of work but we are a big community and we like to keep us
> >>>> busy.
> >>>>
> >>>> What do you think?
> >>>>
> >>>> Jacopo
> >>>>
> >>>>
>

--
I am hongs

[Malin Nicolas]

Hi,

At this time, applications components embedded functional framework and
business oriented (massively B2C) and aren't user friendly.
I possible solution will be have a dedicate application components for
only Consultant or high level user that contains only the functional
framework (with business process cleaned) and for end user an oriented
business components

Exemple :

application /
         content
         humanres
         manufacturing
         marketing
         order
         party
         product
         workeffort

specialpurpose :
        cms
        edm
        ecommerce
        order-b2b
        crm-b2b
        ...

The business components contains (in a beautiful world) only business
service process and simplified screen.
We work with Apache OFBiz on hight parameter ERP  with dynamic (by
jquery through screen engine) reusable screen based on portlet and
portal page. Own idea is, the application components give a portlets
list that business components use to configure their portal page.

I'm not a modularity fan. For the technical framework, is great but I'm
much more mixed to use on functional framework. Integration problem will
not resolve easily.

Nicolas

Le 14/03/2012 23:04, Tom Burns a écrit :

> Adrian / Jacopo
>
> While thinking about a refactoring the OFBiz Architecture you
> may want to look at http://www.aosabook.org/en/intro.html. The book is all
> about Open Source architecture. In particular see the chapter on Eclipse, the
> ultimate open source component framework, Eclipse is the perfect environment to
> implement Adrian's ambitious vision.
>  
> However the most pressing problem in OFBiz, given the
> available resources, is not the architecture, rearranging the components or refactoring
> of what in Moque would be the Core / Mantel (i.e. a scripting framework etc.).
>  
> Rather the problem, as your most recent post to this thread
> suggest, is the short comings in the OFBiz Crust. OOB the user facing
> applications are difficult to understand, quirky and do not support needed business
> requirements. Just ask yourself would you go into a meeting with Steve Jobs ghost
> with these applications?
>  
> On the OFBiz home page "What is Apache OFBiz" the
> focus is clearly ERP. The bullet points advertise OOB application
> functionality. The business applications should be easy to use, robust, and well
> documented. This will require more attention to business requirements,
> providing a consistent set of defined services, adherence to documented UI best
> practices and well written and better presented user help.
>  
> All of this is possible without doing more additional work
> on the Core / Mantel.
>  
> I would be happy to contribute to an effort to improve the
> user facing applications if there is support from the committers.
>  
> I see these applications as falling into two categories. Applications
> that are common to most businesses and domain specific applications. This
> follows the pattern laid out in the two DMR Books. The former, more general,
> category should get the most attention. Those applications include:
> Common Business - Requirements common to most businesses
>   Accounting
>   Human Resources
>   Marketing
>   Work Effort
>   Reporting
>   Document Management
>   E-Commerce
>   Others to be
> identified
>   I would like to start with Human Resources. Is anyone interested?
>
> Tom
>
>
>
> ________________________________
>   From: Pierre Smits<[hidden email]>
> To: [hidden email]
> Sent: Wednesday, March 14, 2012 5:53 PM
> Subject: Re: Rethinking the structure of the OFBiz Applications Components
>
> Hi Adrian,
>
> Could you list the applications you comment out in your production
> implementations? I think that would help creating insight.
>
> Regards,
>
> Pierre
>
> Op 14 maart 2012 18:33 schreef Adrian Crum<
> [hidden email]>  het volgende:
>
>> Understood.
>>
>> As a service provider, I regularly comment out unused applications and
>> build hot-deploy components to replace OOTB OFBiz components. I override
>> service definitions, redefine entity definitions, etc - all in an effort to
>> take what's good in OFBiz, and replace what's not-so-good. I seem to be
>> doing a lot more of it lately - mostly due to components being added that
>> break every other component. At least with a component approach, that sort
>> of thing can be isolated and dealt with.
>>
>> -Adrian
>>
>>
>> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
>>
>>> Thank you Adrian.
>>>
>>> Just to clarify that I was not talking about the architecture of the
>>> framework (topic for another day) but only for the layout of the
>>> applications and it is not based on what I think it is best in general but
>>> instead about what I think it is best to represent what we have right now:
>>> what we have right now is *one* big application (made of mostly all the
>>> components under the "applications" folder) that is split into chunks (the
>>> components) where each chunk is not built to be used alone.
>>> I would be really interested to know from the users of the "applications"
>>> how many of them are removing (or not deploying) the components they do not
>>> need in their business.
>>>
>>> All in all I am trying to better represent (in a more convenient,
>>> cheaper, easier to maintain way) what we already have, not to suggest how
>>> the perfect application built on OFBiz should be. The approach that you are
>>> suggesting on the other hand, that is inspiring, implies a complete
>>> refactoring and redesign (also in terms of features) of the applications.
>>>
>>> Jacopo
>>>
>>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>>>
>>>    That approach sounds very monolithic, and I tend to avoid monoliths.
>>>> I gave this subject a lot of thought about a year ago when I was working
>>>> on a vision for a new framework (https://cwiki.apache.org/**
>>>> confluence/display/OFBADMIN/**Another+Framework+Vision<https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision>).
>>>> In particular, I was trying to devise a way for us to build a new
>>>> architecture for OFBiz out of well-defined and self-contained parts - with
>>>> the ultimate goal of using OSGI to connect them all together.
>>>>
>>>> That goal led to only one pattern that seemed to work: Hub-and-spoke.
>>>> Hubs can be suspended, replaced, and restarted without too much disruption
>>>> because they affect only the spokes connected to them.
>>>>
>>>> It sounds like what you're proposing is a layered pattern - like a wall
>>>> built up of many bricks, but with an all-covering capstone on top.
>>>>
>>>> I don't have a strong opinion on which approach is best, but I tend to
>>>> favor modularity.
>>>>
>>>> The discussion is worthwhile, and I appreciate you starting it.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>>>
>>>>> In the eraly days of the project, the OFBiz applications have been
>>>>> designed as independent components to make them more reusable and because
>>>>> they were designed to be a set of reusable and generic artifacts, each of
>>>>> them based on a specific domain of the data model (order, party, product
>>>>> etc...).
>>>>> They were not intended to be ready to be used out of the box; they were
>>>>> not intended to implement complete ERP workflows (mostly all complete real
>>>>> World workflows encompass several domains) but rather to provide some
>>>>> common artifacts (screens, forms, basic business rules) to facilitate the
>>>>> implementation of custom applications.
>>>>> However over the years, they have been implemented to be used as being
>>>>> part of the same big suite of ERP applications: i.e. the building blocks of
>>>>> a specific instance of an ERP system.
>>>>> Some (parts) of them have become "ready to be used" out of the box (for
>>>>> certain specific business models) by implementing more specific workflows
>>>>> (based on some real World requirements coming from companies): because of
>>>>> the fact that there was not a central design and coordination (which
>>>>> industry/business to implement etc...) and because for the same task
>>>>> (shipping, receiving etc...) there are thousands of different valid
>>>>> worflows we have now several workflows in OFBiz that implement similar
>>>>> features but in different alternative ways.
>>>>> It is off topic here to say if this is good (the company user can
>>>>> choose between a series of choices based on the nature of its business and
>>>>> then customize/clean/complete them) or bad (a lot of duplicated code, the
>>>>> applications seem to deal with everything but they are not really really
>>>>> good for anything): however it is a reality that the applications are now
>>>>> more a suite of ERP application (one application) rather than reusable
>>>>> generic artifacts that can be plugged together.
>>>>> In fact the OFBiz Applications are now a set of OFBiz components that
>>>>> are strictly interdependent at several layers (data model, service, ui).
>>>>>
>>>>> In their current status I believe that it would be better to merge them
>>>>> into one big component, the "Apache OFBiz ERP" (or a better name).
>>>>> The component will contain:
>>>>> * the complete data model for the OFBiz application
>>>>> * all the services (Java, Minilang)
>>>>> * all data
>>>>> * one web application (merged from the existing ones); even if
>>>>> initially we could do this in steps and keep them separated as they are now
>>>>> but under the same component
>>>>> * one aggregated and consolidated set of ui labels
>>>>>
>>>>> Even in one component we will have several mechanisms to categorize our
>>>>> artifacts (file names, folders) even if I would suggest to rethink them
>>>>> based on new rules (and only if we need the categorization).
>>>>> We could merge a lot of files (data preparation scripts, screen
>>>>> definitions, service definitions etc...) to make them more consistent. We
>>>>> would also resolve some of the issues with inter-application links and
>>>>> navigation.
>>>>> I am pretty sure that we could end up with less code and easier to
>>>>> organize and maintain.
>>>>>
>>>>> It will also be more practical to reuse this component and extend it
>>>>> from an external hot deploy component: you will have to extend one webapp
>>>>> and then reuse from the official component what you like.
>>>>>
>>>>> This is just the rough ideas and there could be some variants to it: we
>>>>> could isolate all the data model and services into one component and all
>>>>> the applications (ui, screens, controllers, data prep scripts and
>>>>> templates) into another one. etc. etc. etc...
>>>>>
>>>>> It is a lot of work but we are a big community and we like to keep us
>>>>> busy.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Jacopo
>>>>>
>>>>>

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Tom]

Nicolas,

I think your dream OFBiz development environment would be something like what Salesforce.com offers.

They have two tiers for developers - those that code and those that do not. It's a beautiful world!

For those that do not there is powerful visual in the cloud on line development environment where you can create useful apps with db entities, forms, lists etc. using only GUI forms and wizards.

No Java, No XML, No groovy, No ftl, No Mini-Language etc etc.


For coders they have their own java type language in an Eclipse app.Doesn't look like anything like that is on the radar for OFBiz but if it was available I'd bet it would satisfy a large percentage of the customization needs.

Tom



________________________________
 From: Nicolas Malin <[hidden email]>
To: [hidden email]
Sent: Thursday, March 15, 2012 5:20 AM
Subject: Re: Rethinking the structure of the OFBiz Applications Components
 
Hi,

At this time, applications components embedded functional framework and business oriented (massively B2C) and aren't user friendly.
I possible solution will be have a dedicate application components for only Consultant or high level user that contains only the functional framework (with business process cleaned) and for end user an oriented business components

Exemple :

application /
        content
        humanres
        manufacturing
        marketing
        order
        party
        product
        workeffort

specialpurpose :
       cms
       edm
       ecommerce
       order-b2b
       crm-b2b
       ...

The business components contains (in a beautiful world) only business service process and simplified screen.
We work with Apache OFBiz on hight parameter ERP  with dynamic (by jquery through screen engine) reusable screen based on portlet and portal page. Own idea is, the application components give a portlets list that business components use to configure their portal page.

I'm not a modularity fan. For the technical framework, is great but I'm much more mixed to use on functional framework. Integration problem will not resolve easily.

Nicolas

Le 14/03/2012 23:04, Tom Burns a écrit :

> Adrian / Jacopo
>
> While thinking about a refactoring the OFBiz Architecture you
> may want to look at http://www.aosabook.org/en/intro.html. The book is all
> about Open Source architecture. In particular see the chapter on Eclipse, the
> ultimate open source component framework, Eclipse is the perfect environment to
> implement Adrian's ambitious vision.
>   However the most pressing problem in OFBiz, given the
> available resources, is not the architecture, rearranging the components or refactoring
> of what in Moque would be the Core / Mantel (i.e. a scripting framework etc.).
>   Rather the problem, as your most recent post to this thread
> suggest, is the short comings in the OFBiz Crust. OOB the user facing
> applications are difficult to understand, quirky and do not support needed business
> requirements. Just ask yourself would you go into a meeting with Steve Jobs ghost
> with these applications?
>   On the OFBiz home page "What is Apache OFBiz" the
> focus is clearly ERP. The bullet points advertise OOB application
> functionality. The business applications should be easy to use, robust, and well
> documented. This will require more attention to business requirements,
> providing a consistent set of defined services, adherence to documented UI best
> practices and well written and better presented user help.
>   All of this is possible without doing more additional work
> on the Core / Mantel.
>   I would be happy to contribute to an effort to improve the
> user facing applications if there is support from the committers.
>   I see these applications as falling into two categories. Applications
> that are common to most businesses and domain specific applications. This
> follows the pattern laid out in the two DMR Books. The former, more general,
> category should get the most attention. Those applications include:
> Common Business - Requirements common to most businesses
>   Accounting
>   Human Resources
>   Marketing
>   Work Effort
>   Reporting
>   Document Management
>   E-Commerce
>   Others to be
> identified
>   I would like to start with Human Resources. Is anyone interested?
>
> Tom
>
>
>
> ________________________________
>   From: Pierre Smits<[hidden email]>
> To: [hidden email]
> Sent: Wednesday, March 14, 2012 5:53 PM
> Subject: Re: Rethinking the structure of the OFBiz Applications Components
>
> Hi Adrian,
>
> Could you list the applications you comment out in your production
> implementations? I think that would help creating insight.
>
> Regards,
>
> Pierre
>
> Op 14 maart 2012 18:33 schreef Adrian Crum<
> [hidden email]>  het volgende:
>
>> Understood.
>>
>> As a service provider, I regularly comment out unused applications and
>> build hot-deploy components to replace OOTB OFBiz components. I override
>> service definitions, redefine entity definitions, etc - all in an effort to
>> take what's good in OFBiz, and replace what's not-so-good. I seem to be
>> doing a lot more of it lately - mostly due to components being added that
>> break every other component. At least with a component approach, that sort
>> of thing can be isolated and dealt with.
>>
>> -Adrian
>>
>>
>> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
>>
>>> Thank you Adrian.
>>>
>>> Just to clarify that I was not talking about the architecture of the
>>> framework (topic for another day) but only for the layout of the
>>> applications and it is not based on what I think it is best in general but
>>> instead about what I think it is best to represent what we have right now:
>>> what we have right now is *one* big application (made of mostly all the
>>> components under the "applications" folder) that is split into chunks (the
>>> components) where each chunk is not built to be used alone.
>>> I would be really interested to know from the users of the "applications"
>>> how many of them are removing (or not deploying) the components they do not
>>> need in their business.
>>>
>>> All in all I am trying to better represent (in a more convenient,
>>> cheaper, easier to maintain way) what we already have, not to suggest how
>>> the perfect application built on OFBiz should be. The approach that you are
>>> suggesting on the other hand, that is inspiring, implies a complete
>>> refactoring and redesign (also in terms of features) of the applications.
>>>
>>> Jacopo
>>>
>>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>>>
>>>    That approach sounds very monolithic, and I tend to avoid monoliths.
>>>> I gave this subject a lot of thought about a year ago when I was working
>>>> on a vision for a new framework (https://cwiki.apache.org/**
>>>> confluence/display/OFBADMIN/**Another+Framework+Vision<https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision>).
>>>> In particular, I was trying to devise a way for us to build a new
>>>> architecture for OFBiz out of well-defined and self-contained parts - with
>>>> the ultimate goal of using OSGI to connect them all together.
>>>>
>>>> That goal led to only one pattern that seemed to work: Hub-and-spoke.
>>>> Hubs can be suspended, replaced, and restarted without too much disruption
>>>> because they affect only the spokes connected to them.
>>>>
>>>> It sounds like what you're proposing is a layered pattern - like a wall
>>>> built up of many bricks, but with an all-covering capstone on top.
>>>>
>>>> I don't have a strong opinion on which approach is best, but I tend to
>>>> favor modularity.
>>>>
>>>> The discussion is worthwhile, and I appreciate you starting it.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>>>
>>>>> In the eraly days of the project, the OFBiz applications have been
>>>>> designed as independent components to make them more reusable and because
>>>>> they were designed to be a set of reusable and generic artifacts, each of
>>>>> them based on a specific domain of the data model (order, party, product
>>>>> etc...).
>>>>> They were not intended to be ready to be used out of the box; they were
>>>>> not intended to implement complete ERP workflows (mostly all complete real
>>>>> World workflows encompass several domains) but rather to provide some
>>>>> common artifacts (screens, forms, basic business rules) to facilitate the
>>>>> implementation of custom applications.
>>>>> However over the years, they have been implemented to be used as being
>>>>> part of the same big suite of ERP applications: i.e. the building blocks of
>>>>> a specific instance of an ERP system.
>>>>> Some (parts) of them have become "ready to be used" out of the box (for
>>>>> certain specific business models) by implementing more specific workflows
>>>>> (based on some real World requirements coming from companies): because of
>>>>> the fact that there was not a central design and coordination (which
>>>>> industry/business to implement etc...) and because for the same task
>>>>> (shipping, receiving etc...) there are thousands of different valid
>>>>> worflows we have now several workflows in OFBiz that implement similar
>>>>> features but in different alternative ways.
>>>>> It is off topic here to say if this is good (the company user can
>>>>> choose between a series of choices based on the nature of its business and
>>>>> then customize/clean/complete them) or bad (a lot of duplicated code, the
>>>>> applications seem to deal with everything but they are not really really
>>>>> good for anything): however it is a reality that the applications are now
>>>>> more a suite of ERP application (one application) rather than reusable
>>>>> generic artifacts that can be plugged together.
>>>>> In fact the OFBiz Applications are now a set of OFBiz components that
>>>>> are strictly interdependent at several layers (data model, service, ui).
>>>>>
>>>>> In their current status I believe that it would be better to merge them
>>>>> into one big component, the "Apache OFBiz ERP" (or a better name).
>>>>> The component will contain:
>>>>> * the complete data model for the OFBiz application
>>>>> * all the services (Java, Minilang)
>>>>> * all data
>>>>> * one web application (merged from the existing ones); even if
>>>>> initially we could do this in steps and keep them separated as they are now
>>>>> but under the same component
>>>>> * one aggregated and consolidated set of ui labels
>>>>>
>>>>> Even in one component we will have several mechanisms to categorize our
>>>>> artifacts (file names, folders) even if I would suggest to rethink them
>>>>> based on new rules (and only if we need the categorization).
>>>>> We could merge a lot of files (data preparation scripts, screen
>>>>> definitions, service definitions etc...) to make them more consistent. We
>>>>> would also resolve some of the issues with inter-application links and
>>>>> navigation.
>>>>> I am pretty sure that we could end up with less code and easier to
>>>>> organize and maintain.
>>>>>
>>>>> It will also be more practical to reuse this component and extend it
>>>>> from an external hot deploy component: you will have to extend one webapp
>>>>> and then reuse from the official component what you like.
>>>>>
>>>>> This is just the rough ideas and there could be some variants to it: we
>>>>> could isolate all the data model and services into one component and all
>>>>> the applications (ui, screens, controllers, data prep scripts and
>>>>> templates) into another one. etc. etc. etc...
>>>>>
>>>>> It is a lot of work but we are a big community and we like to keep us
>>>>> busy.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Jacopo
>>>>>
>>>>>

-- Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Anne Jessel]

Perhaps user interface project(s) would be a good fit for the proposed
Apache Extras? Our experience is that one interface does not "fit
all". Having different ones to choose from might be helpful for many
people.

Cheers,
Anne.


On 15 March 2012 20:20, Nicolas Malin <[hidden email]> wrote:

> Hi,
>
> At this time, applications components embedded functional framework and
> business oriented (massively B2C) and aren't user friendly.
> I possible solution will be have a dedicate application components for only
> Consultant or high level user that contains only the functional framework
> (with business process cleaned) and for end user an oriented business
> components
>
> Exemple :
>
> application /
>        content
>        humanres
>        manufacturing
>        marketing
>        order
>        party
>        product
>        workeffort
>
> specialpurpose :
>       cms
>       edm
>       ecommerce
>       order-b2b
>       crm-b2b
>       ...
>
> The business components contains (in a beautiful world) only business
> service process and simplified screen.
> We work with Apache OFBiz on hight parameter ERP  with dynamic (by jquery
> through screen engine) reusable screen based on portlet and portal page. Own
> idea is, the application components give a portlets list that business
> components use to configure their portal page.
>
> I'm not a modularity fan. For the technical framework, is great but I'm much
> more mixed to use on functional framework. Integration problem will not
> resolve easily.
>
> Nicolas
>
> Le 14/03/2012 23:04, Tom Burns a écrit :
>
>> Adrian / Jacopo
>>
>> While thinking about a refactoring the OFBiz Architecture you
>> may want to look at http://www.aosabook.org/en/intro.html. The book is all
>> about Open Source architecture. In particular see the chapter on Eclipse,
>> the
>> ultimate open source component framework, Eclipse is the perfect
>> environment to
>> implement Adrian's ambitious vision.
>>  However the most pressing problem in OFBiz, given the
>> available resources, is not the architecture, rearranging the components
>> or refactoring
>> of what in Moque would be the Core / Mantel (i.e. a scripting framework
>> etc.).
>>  Rather the problem, as your most recent post to this thread
>> suggest, is the short comings in the OFBiz Crust. OOB the user facing
>> applications are difficult to understand, quirky and do not support needed
>> business
>> requirements. Just ask yourself would you go into a meeting with Steve
>> Jobs ghost
>> with these applications?
>>  On the OFBiz home page "What is Apache OFBiz" the
>> focus is clearly ERP. The bullet points advertise OOB application
>> functionality. The business applications should be easy to use, robust,
>> and well
>> documented. This will require more attention to business requirements,
>> providing a consistent set of defined services, adherence to documented UI
>> best
>> practices and well written and better presented user help.
>>  All of this is possible without doing more additional work
>> on the Core / Mantel.
>>  I would be happy to contribute to an effort to improve the
>> user facing applications if there is support from the committers.
>>  I see these applications as falling into two categories. Applications
>> that are common to most businesses and domain specific applications. This
>> follows the pattern laid out in the two DMR Books. The former, more
>> general,
>> category should get the most attention. Those applications include:
>> Common Business - Requirements common to most businesses
>>  Accounting
>>  Human Resources
>>  Marketing
>>  Work Effort
>>  Reporting
>>  Document Management
>>  E-Commerce
>>  Others to be
>> identified
>>  I would like to start with Human Resources. Is anyone interested?
>>
>> Tom
>>
>>
>>
>> ________________________________
>>  From: Pierre Smits<[hidden email]>
>> To: [hidden email]
>> Sent: Wednesday, March 14, 2012 5:53 PM
>> Subject: Re: Rethinking the structure of the OFBiz Applications Components
>>
>> Hi Adrian,
>>
>> Could you list the applications you comment out in your production
>> implementations? I think that would help creating insight.
>>
>> Regards,
>>
>> Pierre
>>
>> Op 14 maart 2012 18:33 schreef Adrian Crum<
>> [hidden email]>  het volgende:
>>
>>> Understood.
>>>
>>> As a service provider, I regularly comment out unused applications and
>>> build hot-deploy components to replace OOTB OFBiz components. I override
>>> service definitions, redefine entity definitions, etc - all in an effort
>>> to
>>> take what's good in OFBiz, and replace what's not-so-good. I seem to be
>>> doing a lot more of it lately - mostly due to components being added that
>>> break every other component. At least with a component approach, that
>>> sort
>>> of thing can be isolated and dealt with.
>>>
>>> -Adrian
>>>
>>>
>>> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
>>>
>>>> Thank you Adrian.
>>>>
>>>> Just to clarify that I was not talking about the architecture of the
>>>> framework (topic for another day) but only for the layout of the
>>>> applications and it is not based on what I think it is best in general
>>>> but
>>>> instead about what I think it is best to represent what we have right
>>>> now:
>>>> what we have right now is *one* big application (made of mostly all the
>>>> components under the "applications" folder) that is split into chunks
>>>> (the
>>>> components) where each chunk is not built to be used alone.
>>>> I would be really interested to know from the users of the
>>>> "applications"
>>>> how many of them are removing (or not deploying) the components they do
>>>> not
>>>> need in their business.
>>>>
>>>> All in all I am trying to better represent (in a more convenient,
>>>> cheaper, easier to maintain way) what we already have, not to suggest
>>>> how
>>>> the perfect application built on OFBiz should be. The approach that you
>>>> are
>>>> suggesting on the other hand, that is inspiring, implies a complete
>>>> refactoring and redesign (also in terms of features) of the
>>>> applications.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>>>>
>>>>   That approach sounds very monolithic, and I tend to avoid monoliths.
>>>>>
>>>>> I gave this subject a lot of thought about a year ago when I was
>>>>> working
>>>>> on a vision for a new framework (https://cwiki.apache.org/**
>>>>>
>>>>> confluence/display/OFBADMIN/**Another+Framework+Vision<https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision>).
>>>>> In particular, I was trying to devise a way for us to build a new
>>>>> architecture for OFBiz out of well-defined and self-contained parts -
>>>>> with
>>>>> the ultimate goal of using OSGI to connect them all together.
>>>>>
>>>>> That goal led to only one pattern that seemed to work: Hub-and-spoke.
>>>>> Hubs can be suspended, replaced, and restarted without too much
>>>>> disruption
>>>>> because they affect only the spokes connected to them.
>>>>>
>>>>> It sounds like what you're proposing is a layered pattern - like a wall
>>>>> built up of many bricks, but with an all-covering capstone on top.
>>>>>
>>>>> I don't have a strong opinion on which approach is best, but I tend to
>>>>> favor modularity.
>>>>>
>>>>> The discussion is worthwhile, and I appreciate you starting it.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>>>>
>>>>>> In the eraly days of the project, the OFBiz applications have been
>>>>>> designed as independent components to make them more reusable and
>>>>>> because
>>>>>> they were designed to be a set of reusable and generic artifacts, each
>>>>>> of
>>>>>> them based on a specific domain of the data model (order, party,
>>>>>> product
>>>>>> etc...).
>>>>>> They were not intended to be ready to be used out of the box; they
>>>>>> were
>>>>>> not intended to implement complete ERP workflows (mostly all complete
>>>>>> real
>>>>>> World workflows encompass several domains) but rather to provide some
>>>>>> common artifacts (screens, forms, basic business rules) to facilitate
>>>>>> the
>>>>>> implementation of custom applications.
>>>>>> However over the years, they have been implemented to be used as being
>>>>>> part of the same big suite of ERP applications: i.e. the building
>>>>>> blocks of
>>>>>> a specific instance of an ERP system.
>>>>>> Some (parts) of them have become "ready to be used" out of the box
>>>>>> (for
>>>>>> certain specific business models) by implementing more specific
>>>>>> workflows
>>>>>> (based on some real World requirements coming from companies): because
>>>>>> of
>>>>>> the fact that there was not a central design and coordination (which
>>>>>> industry/business to implement etc...) and because for the same task
>>>>>> (shipping, receiving etc...) there are thousands of different valid
>>>>>> worflows we have now several workflows in OFBiz that implement similar
>>>>>> features but in different alternative ways.
>>>>>> It is off topic here to say if this is good (the company user can
>>>>>> choose between a series of choices based on the nature of its business
>>>>>> and
>>>>>> then customize/clean/complete them) or bad (a lot of duplicated code,
>>>>>> the
>>>>>> applications seem to deal with everything but they are not really
>>>>>> really
>>>>>> good for anything): however it is a reality that the applications are
>>>>>> now
>>>>>> more a suite of ERP application (one application) rather than reusable
>>>>>> generic artifacts that can be plugged together.
>>>>>> In fact the OFBiz Applications are now a set of OFBiz components that
>>>>>> are strictly interdependent at several layers (data model, service,
>>>>>> ui).
>>>>>>
>>>>>> In their current status I believe that it would be better to merge
>>>>>> them
>>>>>> into one big component, the "Apache OFBiz ERP" (or a better name).
>>>>>> The component will contain:
>>>>>> * the complete data model for the OFBiz application
>>>>>> * all the services (Java, Minilang)
>>>>>> * all data
>>>>>> * one web application (merged from the existing ones); even if
>>>>>> initially we could do this in steps and keep them separated as they
>>>>>> are now
>>>>>> but under the same component
>>>>>> * one aggregated and consolidated set of ui labels
>>>>>>
>>>>>> Even in one component we will have several mechanisms to categorize
>>>>>> our
>>>>>> artifacts (file names, folders) even if I would suggest to rethink
>>>>>> them
>>>>>> based on new rules (and only if we need the categorization).
>>>>>> We could merge a lot of files (data preparation scripts, screen
>>>>>> definitions, service definitions etc...) to make them more consistent.
>>>>>> We
>>>>>> would also resolve some of the issues with inter-application links and
>>>>>> navigation.
>>>>>> I am pretty sure that we could end up with less code and easier to
>>>>>> organize and maintain.
>>>>>>
>>>>>> It will also be more practical to reuse this component and extend it
>>>>>> from an external hot deploy component: you will have to extend one
>>>>>> webapp
>>>>>> and then reuse from the official component what you like.
>>>>>>
>>>>>> This is just the rough ideas and there could be some variants to it:
>>>>>> we
>>>>>> could isolate all the data model and services into one component and
>>>>>> all
>>>>>> the applications (ui, screens, controllers, data prep scripts and
>>>>>> templates) into another one. etc. etc. etc...
>>>>>>
>>>>>> It is a lot of work but we are a big community and we like to keep us
>>>>>> busy.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>
>
> --
> Nicolas MALIN
> Consultant
> Tél : [phone]
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : [phone]
> Site : http://www.librenberry.net/
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[Pierre Smits]

I think the entire set of example functionalities should be removed from
the core and moved over to either the special purpose section. I also
believe that the marketing/sfa application should be split up and moved to
special purpose.

Regards,

Pierre


Op 16 maart 2012 00:47 schreef Anne <[hidden email]> het volgende:

> Perhaps user interface project(s) would be a good fit for the proposed
> Apache Extras? Our experience is that one interface does not "fit
> all". Having different ones to choose from might be helpful for many
> people.
>
> Cheers,
> Anne.
>
>
> On 15 March 2012 20:20, Nicolas Malin <[hidden email]>
> wrote:
> > Hi,
> >
> > At this time, applications components embedded functional framework and
> > business oriented (massively B2C) and aren't user friendly.
> > I possible solution will be have a dedicate application components for
> only
> > Consultant or high level user that contains only the functional framework
> > (with business process cleaned) and for end user an oriented business
> > components
> >
> > Exemple :
> >
> > application /
> >        content
> >        humanres
> >        manufacturing
> >        marketing
> >        order
> >        party
> >        product
> >        workeffort
> >
> > specialpurpose :
> >       cms
> >       edm
> >       ecommerce
> >       order-b2b
> >       crm-b2b
> >       ...
> >
> > The business components contains (in a beautiful world) only business
> > service process and simplified screen.
> > We work with Apache OFBiz on hight parameter ERP  with dynamic (by jquery
> > through screen engine) reusable screen based on portlet and portal page.
> Own
> > idea is, the application components give a portlets list that business
> > components use to configure their portal page.
> >
> > I'm not a modularity fan. For the technical framework, is great but I'm
> much
> > more mixed to use on functional framework. Integration problem will not
> > resolve easily.
> >
> > Nicolas
> >
> > Le 14/03/2012 23:04, Tom Burns a écrit :
> >
> >> Adrian / Jacopo
> >>
> >> While thinking about a refactoring the OFBiz Architecture you
> >> may want to look at http://www.aosabook.org/en/intro.html. The book is
> all
> >> about Open Source architecture. In particular see the chapter on
> Eclipse,
> >> the
> >> ultimate open source component framework, Eclipse is the perfect
> >> environment to
> >> implement Adrian's ambitious vision.
> >>  However the most pressing problem in OFBiz, given the
> >> available resources, is not the architecture, rearranging the components
> >> or refactoring
> >> of what in Moque would be the Core / Mantel (i.e. a scripting framework
> >> etc.).
> >>  Rather the problem, as your most recent post to this thread
> >> suggest, is the short comings in the OFBiz Crust. OOB the user facing
> >> applications are difficult to understand, quirky and do not support
> needed
> >> business
> >> requirements. Just ask yourself would you go into a meeting with Steve
> >> Jobs ghost
> >> with these applications?
> >>  On the OFBiz home page "What is Apache OFBiz" the
> >> focus is clearly ERP. The bullet points advertise OOB application
> >> functionality. The business applications should be easy to use, robust,
> >> and well
> >> documented. This will require more attention to business requirements,
> >> providing a consistent set of defined services, adherence to documented
> UI
> >> best
> >> practices and well written and better presented user help.
> >>  All of this is possible without doing more additional work
> >> on the Core / Mantel.
> >>  I would be happy to contribute to an effort to improve the
> >> user facing applications if there is support from the committers.
> >>  I see these applications as falling into two categories. Applications
> >> that are common to most businesses and domain specific applications.
> This
> >> follows the pattern laid out in the two DMR Books. The former, more
> >> general,
> >> category should get the most attention. Those applications include:
> >> Common Business - Requirements common to most businesses
> >>  Accounting
> >>  Human Resources
> >>  Marketing
> >>  Work Effort
> >>  Reporting
> >>  Document Management
> >>  E-Commerce
> >>  Others to be
> >> identified
> >>  I would like to start with Human Resources. Is anyone interested?
> >>
> >> Tom
> >>
> >>
> >>
> >> ________________________________
> >>  From: Pierre Smits<[hidden email]>
> >> To: [hidden email]
> >> Sent: Wednesday, March 14, 2012 5:53 PM
> >> Subject: Re: Rethinking the structure of the OFBiz Applications
> Components
> >>
> >> Hi Adrian,
> >>
> >> Could you list the applications you comment out in your production
> >> implementations? I think that would help creating insight.
> >>
> >> Regards,
> >>
> >> Pierre
> >>
> >> Op 14 maart 2012 18:33 schreef Adrian Crum<
> >> [hidden email]>  het volgende:
> >>
> >>> Understood.
> >>>
> >>> As a service provider, I regularly comment out unused applications and
> >>> build hot-deploy components to replace OOTB OFBiz components. I
> override
> >>> service definitions, redefine entity definitions, etc - all in an
> effort
> >>> to
> >>> take what's good in OFBiz, and replace what's not-so-good. I seem to be
> >>> doing a lot more of it lately - mostly due to components being added
> that
> >>> break every other component. At least with a component approach, that
> >>> sort
> >>> of thing can be isolated and dealt with.
> >>>
> >>> -Adrian
> >>>
> >>>
> >>> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
> >>>
> >>>> Thank you Adrian.
> >>>>
> >>>> Just to clarify that I was not talking about the architecture of the
> >>>> framework (topic for another day) but only for the layout of the
> >>>> applications and it is not based on what I think it is best in general
> >>>> but
> >>>> instead about what I think it is best to represent what we have right
> >>>> now:
> >>>> what we have right now is *one* big application (made of mostly all
> the
> >>>> components under the "applications" folder) that is split into chunks
> >>>> (the
> >>>> components) where each chunk is not built to be used alone.
> >>>> I would be really interested to know from the users of the
> >>>> "applications"
> >>>> how many of them are removing (or not deploying) the components they
> do
> >>>> not
> >>>> need in their business.
> >>>>
> >>>> All in all I am trying to better represent (in a more convenient,
> >>>> cheaper, easier to maintain way) what we already have, not to suggest
> >>>> how
> >>>> the perfect application built on OFBiz should be. The approach that
> you
> >>>> are
> >>>> suggesting on the other hand, that is inspiring, implies a complete
> >>>> refactoring and redesign (also in terms of features) of the
> >>>> applications.
> >>>>
> >>>> Jacopo
> >>>>
> >>>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
> >>>>
> >>>>   That approach sounds very monolithic, and I tend to avoid monoliths.
> >>>>>
> >>>>> I gave this subject a lot of thought about a year ago when I was
> >>>>> working
> >>>>> on a vision for a new framework (https://cwiki.apache.org/**
> >>>>>
> >>>>> confluence/display/OFBADMIN/**Another+Framework+Vision<
> https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
> >).
> >>>>> In particular, I was trying to devise a way for us to build a new
> >>>>> architecture for OFBiz out of well-defined and self-contained parts -
> >>>>> with
> >>>>> the ultimate goal of using OSGI to connect them all together.
> >>>>>
> >>>>> That goal led to only one pattern that seemed to work: Hub-and-spoke.
> >>>>> Hubs can be suspended, replaced, and restarted without too much
> >>>>> disruption
> >>>>> because they affect only the spokes connected to them.
> >>>>>
> >>>>> It sounds like what you're proposing is a layered pattern - like a
> wall
> >>>>> built up of many bricks, but with an all-covering capstone on top.
> >>>>>
> >>>>> I don't have a strong opinion on which approach is best, but I tend
> to
> >>>>> favor modularity.
> >>>>>
> >>>>> The discussion is worthwhile, and I appreciate you starting it.
> >>>>>
> >>>>> -Adrian
> >>>>>
> >>>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
> >>>>>
> >>>>>> In the eraly days of the project, the OFBiz applications have been
> >>>>>> designed as independent components to make them more reusable and
> >>>>>> because
> >>>>>> they were designed to be a set of reusable and generic artifacts,
> each
> >>>>>> of
> >>>>>> them based on a specific domain of the data model (order, party,
> >>>>>> product
> >>>>>> etc...).
> >>>>>> They were not intended to be ready to be used out of the box; they
> >>>>>> were
> >>>>>> not intended to implement complete ERP workflows (mostly all
> complete
> >>>>>> real
> >>>>>> World workflows encompass several domains) but rather to provide
> some
> >>>>>> common artifacts (screens, forms, basic business rules) to
> facilitate
> >>>>>> the
> >>>>>> implementation of custom applications.
> >>>>>> However over the years, they have been implemented to be used as
> being
> >>>>>> part of the same big suite of ERP applications: i.e. the building
> >>>>>> blocks of
> >>>>>> a specific instance of an ERP system.
> >>>>>> Some (parts) of them have become "ready to be used" out of the box
> >>>>>> (for
> >>>>>> certain specific business models) by implementing more specific
> >>>>>> workflows
> >>>>>> (based on some real World requirements coming from companies):
> because
> >>>>>> of
> >>>>>> the fact that there was not a central design and coordination (which
> >>>>>> industry/business to implement etc...) and because for the same task
> >>>>>> (shipping, receiving etc...) there are thousands of different valid
> >>>>>> worflows we have now several workflows in OFBiz that implement
> similar
> >>>>>> features but in different alternative ways.
> >>>>>> It is off topic here to say if this is good (the company user can
> >>>>>> choose between a series of choices based on the nature of its
> business
> >>>>>> and
> >>>>>> then customize/clean/complete them) or bad (a lot of duplicated
> code,
> >>>>>> the
> >>>>>> applications seem to deal with everything but they are not really
> >>>>>> really
> >>>>>> good for anything): however it is a reality that the applications
> are
> >>>>>> now
> >>>>>> more a suite of ERP application (one application) rather than
> reusable
> >>>>>> generic artifacts that can be plugged together.
> >>>>>> In fact the OFBiz Applications are now a set of OFBiz components
> that
> >>>>>> are strictly interdependent at several layers (data model, service,
> >>>>>> ui).
> >>>>>>
> >>>>>> In their current status I believe that it would be better to merge
> >>>>>> them
> >>>>>> into one big component, the "Apache OFBiz ERP" (or a better name).
> >>>>>> The component will contain:
> >>>>>> * the complete data model for the OFBiz application
> >>>>>> * all the services (Java, Minilang)
> >>>>>> * all data
> >>>>>> * one web application (merged from the existing ones); even if
> >>>>>> initially we could do this in steps and keep them separated as they
> >>>>>> are now
> >>>>>> but under the same component
> >>>>>> * one aggregated and consolidated set of ui labels
> >>>>>>
> >>>>>> Even in one component we will have several mechanisms to categorize
> >>>>>> our
> >>>>>> artifacts (file names, folders) even if I would suggest to rethink
> >>>>>> them
> >>>>>> based on new rules (and only if we need the categorization).
> >>>>>> We could merge a lot of files (data preparation scripts, screen
> >>>>>> definitions, service definitions etc...) to make them more
> consistent.
> >>>>>> We
> >>>>>> would also resolve some of the issues with inter-application links
> and
> >>>>>> navigation.
> >>>>>> I am pretty sure that we could end up with less code and easier to
> >>>>>> organize and maintain.
> >>>>>>
> >>>>>> It will also be more practical to reuse this component and extend it
> >>>>>> from an external hot deploy component: you will have to extend one
> >>>>>> webapp
> >>>>>> and then reuse from the official component what you like.
> >>>>>>
> >>>>>> This is just the rough ideas and there could be some variants to it:
> >>>>>> we
> >>>>>> could isolate all the data model and services into one component and
> >>>>>> all
> >>>>>> the applications (ui, screens, controllers, data prep scripts and
> >>>>>> templates) into another one. etc. etc. etc...
> >>>>>>
> >>>>>> It is a lot of work but we are a big community and we like to keep
> us
> >>>>>> busy.
> >>>>>>
> >>>>>> What do you think?
> >>>>>>
> >>>>>> Jacopo
> >>>>>>
> >>>>>>
> >
> >
> > --
> > Nicolas MALIN
> > Consultant
> > Tél : [phone]
> > Site projet : http://www.neogia.org/
> > -------
> > Société LibrenBerry
> > Tél : [phone]
> > Site : http://www.librenberry.net/
> >
>
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Phone: [phone]
> Fax: [phone]
> Web: http://www.cohsoft.com.au/
> Email: [hidden email]
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>

[Erwan de FERRIERES]

Le 14/03/2012 23:04, Tom Burns a écrit :

> I see these applications as falling into two categories. Applications
> that are common to most businesses and domain specific applications. This
> follows the pattern laid out in the two DMR Books. The former, more general,
> category should get the most attention. Those applications include:
> Common Business - Requirements common to most businesses
>   Accounting
>   Human Resources
>   Marketing
>   Work Effort
>   Reporting
>   Document Management
>   E-Commerce
>   Others to be
> identified
>   I would like to start with Human Resources. Is anyone interested?
>
> Tom
>
>

+1

--
Erwan de FERRIERES
www.nereide.biz

[Malin Nicolas]

Le 16/03/2012 00:47, Anne a écrit :
> Perhaps user interface project(s) would be a good fit for the proposed
> Apache Extras? Our experience is that one interface does not "fit
> all". Having different ones to choose from might be helpful for many
> people.
It's the goal :)
All addons name portlet-* contains a beginning standard ofbiz screen
conversion to functional portlet.

You can see some examples here :
  https://demo.neogia.org/consultantb2b/ an consultant oriented
interface that use massively projectmgr and workeffort portlet, and also
content, party, order portlet. All parameterized through portalPage (so
easy to remove or update some portlet)

  https://demo.neogia.org/salesreps for commercial, use content, party,
order and marketing portlet. For party, some portlets are also use on
consultantb2b components but we change just the role has filter.

The demo server not up to date, I will update it this week.

Nicolas

> Cheers,
> Anne.
>
>
> On 15 March 2012 20:20, Nicolas Malin<[hidden email]>  wrote:
>> Hi,
>>
>> At this time, applications components embedded functional framework and
>> business oriented (massively B2C) and aren't user friendly.
>> I possible solution will be have a dedicate application components for only
>> Consultant or high level user that contains only the functional framework
>> (with business process cleaned) and for end user an oriented business
>> components
>>
>> Exemple :
>>
>> application /
>>         content
>>         humanres
>>         manufacturing
>>         marketing
>>         order
>>         party
>>         product
>>         workeffort
>>
>> specialpurpose :
>>        cms
>>        edm
>>        ecommerce
>>        order-b2b
>>        crm-b2b
>>        ...
>>
>> The business components contains (in a beautiful world) only business
>> service process and simplified screen.
>> We work with Apache OFBiz on hight parameter ERP  with dynamic (by jquery
>> through screen engine) reusable screen based on portlet and portal page. Own
>> idea is, the application components give a portlets list that business
>> components use to configure their portal page.
>>
>> I'm not a modularity fan. For the technical framework, is great but I'm much
>> more mixed to use on functional framework. Integration problem will not
>> resolve easily.
>>
>> Nicolas
>>
>> Le 14/03/2012 23:04, Tom Burns a écrit :
>>
>>> Adrian / Jacopo
>>>
>>> While thinking about a refactoring the OFBiz Architecture you
>>> may want to look at http://www.aosabook.org/en/intro.html. The book is all
>>> about Open Source architecture. In particular see the chapter on Eclipse,
>>> the
>>> ultimate open source component framework, Eclipse is the perfect
>>> environment to
>>> implement Adrian's ambitious vision.
>>>   However the most pressing problem in OFBiz, given the
>>> available resources, is not the architecture, rearranging the components
>>> or refactoring
>>> of what in Moque would be the Core / Mantel (i.e. a scripting framework
>>> etc.).
>>>   Rather the problem, as your most recent post to this thread
>>> suggest, is the short comings in the OFBiz Crust. OOB the user facing
>>> applications are difficult to understand, quirky and do not support needed
>>> business
>>> requirements. Just ask yourself would you go into a meeting with Steve
>>> Jobs ghost
>>> with these applications?
>>>   On the OFBiz home page "What is Apache OFBiz" the
>>> focus is clearly ERP. The bullet points advertise OOB application
>>> functionality. The business applications should be easy to use, robust,
>>> and well
>>> documented. This will require more attention to business requirements,
>>> providing a consistent set of defined services, adherence to documented UI
>>> best
>>> practices and well written and better presented user help.
>>>   All of this is possible without doing more additional work
>>> on the Core / Mantel.
>>>   I would be happy to contribute to an effort to improve the
>>> user facing applications if there is support from the committers.
>>>   I see these applications as falling into two categories. Applications
>>> that are common to most businesses and domain specific applications. This
>>> follows the pattern laid out in the two DMR Books. The former, more
>>> general,
>>> category should get the most attention. Those applications include:
>>> Common Business - Requirements common to most businesses
>>>   Accounting
>>>   Human Resources
>>>   Marketing
>>>   Work Effort
>>>   Reporting
>>>   Document Management
>>>   E-Commerce
>>>   Others to be
>>> identified
>>>   I would like to start with Human Resources. Is anyone interested?
>>>
>>> Tom
>>>
>>>
>>>
>>> ________________________________
>>>   From: Pierre Smits<[hidden email]>
>>> To: [hidden email]
>>> Sent: Wednesday, March 14, 2012 5:53 PM
>>> Subject: Re: Rethinking the structure of the OFBiz Applications Components
>>>
>>> Hi Adrian,
>>>
>>> Could you list the applications you comment out in your production
>>> implementations? I think that would help creating insight.
>>>
>>> Regards,
>>>
>>> Pierre
>>>
>>> Op 14 maart 2012 18:33 schreef Adrian Crum<
>>> [hidden email]>    het volgende:
>>>
>>>> Understood.
>>>>
>>>> As a service provider, I regularly comment out unused applications and
>>>> build hot-deploy components to replace OOTB OFBiz components. I override
>>>> service definitions, redefine entity definitions, etc - all in an effort
>>>> to
>>>> take what's good in OFBiz, and replace what's not-so-good. I seem to be
>>>> doing a lot more of it lately - mostly due to components being added that
>>>> break every other component. At least with a component approach, that
>>>> sort
>>>> of thing can be isolated and dealt with.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
>>>>
>>>>> Thank you Adrian.
>>>>>
>>>>> Just to clarify that I was not talking about the architecture of the
>>>>> framework (topic for another day) but only for the layout of the
>>>>> applications and it is not based on what I think it is best in general
>>>>> but
>>>>> instead about what I think it is best to represent what we have right
>>>>> now:
>>>>> what we have right now is *one* big application (made of mostly all the
>>>>> components under the "applications" folder) that is split into chunks
>>>>> (the
>>>>> components) where each chunk is not built to be used alone.
>>>>> I would be really interested to know from the users of the
>>>>> "applications"
>>>>> how many of them are removing (or not deploying) the components they do
>>>>> not
>>>>> need in their business.
>>>>>
>>>>> All in all I am trying to better represent (in a more convenient,
>>>>> cheaper, easier to maintain way) what we already have, not to suggest
>>>>> how
>>>>> the perfect application built on OFBiz should be. The approach that you
>>>>> are
>>>>> suggesting on the other hand, that is inspiring, implies a complete
>>>>> refactoring and redesign (also in terms of features) of the
>>>>> applications.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>>>>>
>>>>>    That approach sounds very monolithic, and I tend to avoid monoliths.
>>>>>> I gave this subject a lot of thought about a year ago when I was
>>>>>> working
>>>>>> on a vision for a new framework (https://cwiki.apache.org/**
>>>>>>
>>>>>> confluence/display/OFBADMIN/**Another+Framework+Vision<https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision>).
>>>>>> In particular, I was trying to devise a way for us to build a new
>>>>>> architecture for OFBiz out of well-defined and self-contained parts -
>>>>>> with
>>>>>> the ultimate goal of using OSGI to connect them all together.
>>>>>>
>>>>>> That goal led to only one pattern that seemed to work: Hub-and-spoke.
>>>>>> Hubs can be suspended, replaced, and restarted without too much
>>>>>> disruption
>>>>>> because they affect only the spokes connected to them.
>>>>>>
>>>>>> It sounds like what you're proposing is a layered pattern - like a wall
>>>>>> built up of many bricks, but with an all-covering capstone on top.
>>>>>>
>>>>>> I don't have a strong opinion on which approach is best, but I tend to
>>>>>> favor modularity.
>>>>>>
>>>>>> The discussion is worthwhile, and I appreciate you starting it.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>>>>>
>>>>>>> In the eraly days of the project, the OFBiz applications have been
>>>>>>> designed as independent components to make them more reusable and
>>>>>>> because
>>>>>>> they were designed to be a set of reusable and generic artifacts, each
>>>>>>> of
>>>>>>> them based on a specific domain of the data model (order, party,
>>>>>>> product
>>>>>>> etc...).
>>>>>>> They were not intended to be ready to be used out of the box; they
>>>>>>> were
>>>>>>> not intended to implement complete ERP workflows (mostly all complete
>>>>>>> real
>>>>>>> World workflows encompass several domains) but rather to provide some
>>>>>>> common artifacts (screens, forms, basic business rules) to facilitate
>>>>>>> the
>>>>>>> implementation of custom applications.
>>>>>>> However over the years, they have been implemented to be used as being
>>>>>>> part of the same big suite of ERP applications: i.e. the building
>>>>>>> blocks of
>>>>>>> a specific instance of an ERP system.
>>>>>>> Some (parts) of them have become "ready to be used" out of the box
>>>>>>> (for
>>>>>>> certain specific business models) by implementing more specific
>>>>>>> workflows
>>>>>>> (based on some real World requirements coming from companies): because
>>>>>>> of
>>>>>>> the fact that there was not a central design and coordination (which
>>>>>>> industry/business to implement etc...) and because for the same task
>>>>>>> (shipping, receiving etc...) there are thousands of different valid
>>>>>>> worflows we have now several workflows in OFBiz that implement similar
>>>>>>> features but in different alternative ways.
>>>>>>> It is off topic here to say if this is good (the company user can
>>>>>>> choose between a series of choices based on the nature of its business
>>>>>>> and
>>>>>>> then customize/clean/complete them) or bad (a lot of duplicated code,
>>>>>>> the
>>>>>>> applications seem to deal with everything but they are not really
>>>>>>> really
>>>>>>> good for anything): however it is a reality that the applications are
>>>>>>> now
>>>>>>> more a suite of ERP application (one application) rather than reusable
>>>>>>> generic artifacts that can be plugged together.
>>>>>>> In fact the OFBiz Applications are now a set of OFBiz components that
>>>>>>> are strictly interdependent at several layers (data model, service,
>>>>>>> ui).
>>>>>>>
>>>>>>> In their current status I believe that it would be better to merge
>>>>>>> them
>>>>>>> into one big component, the "Apache OFBiz ERP" (or a better name).
>>>>>>> The component will contain:
>>>>>>> * the complete data model for the OFBiz application
>>>>>>> * all the services (Java, Minilang)
>>>>>>> * all data
>>>>>>> * one web application (merged from the existing ones); even if
>>>>>>> initially we could do this in steps and keep them separated as they
>>>>>>> are now
>>>>>>> but under the same component
>>>>>>> * one aggregated and consolidated set of ui labels
>>>>>>>
>>>>>>> Even in one component we will have several mechanisms to categorize
>>>>>>> our
>>>>>>> artifacts (file names, folders) even if I would suggest to rethink
>>>>>>> them
>>>>>>> based on new rules (and only if we need the categorization).
>>>>>>> We could merge a lot of files (data preparation scripts, screen
>>>>>>> definitions, service definitions etc...) to make them more consistent.
>>>>>>> We
>>>>>>> would also resolve some of the issues with inter-application links and
>>>>>>> navigation.
>>>>>>> I am pretty sure that we could end up with less code and easier to
>>>>>>> organize and maintain.
>>>>>>>
>>>>>>> It will also be more practical to reuse this component and extend it
>>>>>>> from an external hot deploy component: you will have to extend one
>>>>>>> webapp
>>>>>>> and then reuse from the official component what you like.
>>>>>>>
>>>>>>> This is just the rough ideas and there could be some variants to it:
>>>>>>> we
>>>>>>> could isolate all the data model and services into one component and
>>>>>>> all
>>>>>>> the applications (ui, screens, controllers, data prep scripts and
>>>>>>> templates) into another one. etc. etc. etc...
>>>>>>>
>>>>>>> It is a lot of work but we are a big community and we like to keep us
>>>>>>> busy.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>
>>
>> --
>> Nicolas MALIN
>> Consultant
>> Tél : [phone]
>> Site projet : http://www.neogia.org/
>> -------
>> Société LibrenBerry
>> Tél : [phone]
>> Site : http://www.librenberry.net/
>>
>
>

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Malin Nicolas]

Le 15/03/2012 19:01, Tom Burns a écrit :
> Nicolas,
>
> I think your dream OFBiz development environment would be something like what Salesforce.com offers.
Yes it's a dream, in reality these solution isn't viable to create an
generic ERP has Apache OFBiz.If you scratch, application are so business
oriented, and functional structure miss. Quick write, quick drop :) as
windev.
> They have two tiers for developers - those that code and those that do not. It's a beautiful world!
Code to code maybe, important is the reuse work. In technical is make
easier, but on functional layers few developers happens to do it. And
that is why I love OFBiz ;) . I can code with this aim !

Nicolas

> For those that do not there is powerful visual in the cloud on line development environment where you can create useful apps with db entities, forms, lists etc. using only GUI forms and wizards.
>
> No Java, No XML, No groovy, No ftl, No Mini-Language etc etc.
>
>
> For coders they have their own java type language in an Eclipse app.Doesn't look like anything like that is on the radar for OFBiz but if it was available I'd bet it would satisfy a large percentage of the customization needs.
>
> Tom
>
>
>
> ________________________________
>   From: Nicolas Malin<[hidden email]>
> To: [hidden email]
> Sent: Thursday, March 15, 2012 5:20 AM
> Subject: Re: Rethinking the structure of the OFBiz Applications Components
>
> Hi,
>
> At this time, applications components embedded functional framework and business oriented (massively B2C) and aren't user friendly.
> I possible solution will be have a dedicate application components for only Consultant or high level user that contains only the functional framework (with business process cleaned) and for end user an oriented business components
>
> Exemple :
>
> application /
>          content
>          humanres
>          manufacturing
>          marketing
>          order
>          party
>          product
>          workeffort
>
> specialpurpose :
>         cms
>         edm
>         ecommerce
>         order-b2b
>         crm-b2b
>         ...
>
> The business components contains (in a beautiful world) only business service process and simplified screen.
> We work with Apache OFBiz on hight parameter ERP  with dynamic (by jquery through screen engine) reusable screen based on portlet and portal page. Own idea is, the application components give a portlets list that business components use to configure their portal page.
>
> I'm not a modularity fan. For the technical framework, is great but I'm much more mixed to use on functional framework. Integration problem will not resolve easily.
>
> Nicolas
>
> Le 14/03/2012 23:04, Tom Burns a écrit :
>> Adrian / Jacopo
>>
>> While thinking about a refactoring the OFBiz Architecture you
>> may want to look at http://www.aosabook.org/en/intro.html. The book is all
>> about Open Source architecture. In particular see the chapter on Eclipse, the
>> ultimate open source component framework, Eclipse is the perfect environment to
>> implement Adrian's ambitious vision.
>>     However the most pressing problem in OFBiz, given the
>> available resources, is not the architecture, rearranging the components or refactoring
>> of what in Moque would be the Core / Mantel (i.e. a scripting framework etc.).
>>     Rather the problem, as your most recent post to this thread
>> suggest, is the short comings in the OFBiz Crust. OOB the user facing
>> applications are difficult to understand, quirky and do not support needed business
>> requirements. Just ask yourself would you go into a meeting with Steve Jobs ghost
>> with these applications?
>>     On the OFBiz home page "What is Apache OFBiz" the
>> focus is clearly ERP. The bullet points advertise OOB application
>> functionality. The business applications should be easy to use, robust, and well
>> documented. This will require more attention to business requirements,
>> providing a consistent set of defined services, adherence to documented UI best
>> practices and well written and better presented user help.
>>     All of this is possible without doing more additional work
>> on the Core / Mantel.
>>     I would be happy to contribute to an effort to improve the
>> user facing applications if there is support from the committers.
>>     I see these applications as falling into two categories. Applications
>> that are common to most businesses and domain specific applications. This
>> follows the pattern laid out in the two DMR Books. The former, more general,
>> category should get the most attention. Those applications include:
>> Common Business - Requirements common to most businesses
>>     Accounting
>>     Human Resources
>>     Marketing
>>     Work Effort
>>     Reporting
>>     Document Management
>>     E-Commerce
>>     Others to be
>> identified
>>     I would like to start with Human Resources. Is anyone interested?
>>
>> Tom
>>
>>
>>
>> ________________________________
>>     From: Pierre Smits<[hidden email]>
>> To: [hidden email]
>> Sent: Wednesday, March 14, 2012 5:53 PM
>> Subject: Re: Rethinking the structure of the OFBiz Applications Components
>>
>> Hi Adrian,
>>
>> Could you list the applications you comment out in your production
>> implementations? I think that would help creating insight.
>>
>> Regards,
>>
>> Pierre
>>
>> Op 14 maart 2012 18:33 schreef Adrian Crum<
>> [hidden email]>   het volgende:
>>
>>> Understood.
>>>
>>> As a service provider, I regularly comment out unused applications and
>>> build hot-deploy components to replace OOTB OFBiz components. I override
>>> service definitions, redefine entity definitions, etc - all in an effort to
>>> take what's good in OFBiz, and replace what's not-so-good. I seem to be
>>> doing a lot more of it lately - mostly due to components being added that
>>> break every other component. At least with a component approach, that sort
>>> of thing can be isolated and dealt with.
>>>
>>> -Adrian
>>>
>>>
>>> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
>>>
>>>> Thank you Adrian.
>>>>
>>>> Just to clarify that I was not talking about the architecture of the
>>>> framework (topic for another day) but only for the layout of the
>>>> applications and it is not based on what I think it is best in general but
>>>> instead about what I think it is best to represent what we have right now:
>>>> what we have right now is *one* big application (made of mostly all the
>>>> components under the "applications" folder) that is split into chunks (the
>>>> components) where each chunk is not built to be used alone.
>>>> I would be really interested to know from the users of the "applications"
>>>> how many of them are removing (or not deploying) the components they do not
>>>> need in their business.
>>>>
>>>> All in all I am trying to better represent (in a more convenient,
>>>> cheaper, easier to maintain way) what we already have, not to suggest how
>>>> the perfect application built on OFBiz should be. The approach that you are
>>>> suggesting on the other hand, that is inspiring, implies a complete
>>>> refactoring and redesign (also in terms of features) of the applications.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>>>>
>>>>      That approach sounds very monolithic, and I tend to avoid monoliths.
>>>>> I gave this subject a lot of thought about a year ago when I was working
>>>>> on a vision for a new framework (https://cwiki.apache.org/**
>>>>> confluence/display/OFBADMIN/**Another+Framework+Vision<https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision>).
>>>>> In particular, I was trying to devise a way for us to build a new
>>>>> architecture for OFBiz out of well-defined and self-contained parts - with
>>>>> the ultimate goal of using OSGI to connect them all together.
>>>>>
>>>>> That goal led to only one pattern that seemed to work: Hub-and-spoke.
>>>>> Hubs can be suspended, replaced, and restarted without too much disruption
>>>>> because they affect only the spokes connected to them.
>>>>>
>>>>> It sounds like what you're proposing is a layered pattern - like a wall
>>>>> built up of many bricks, but with an all-covering capstone on top.
>>>>>
>>>>> I don't have a strong opinion on which approach is best, but I tend to
>>>>> favor modularity.
>>>>>
>>>>> The discussion is worthwhile, and I appreciate you starting it.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>>>>
>>>>>> In the eraly days of the project, the OFBiz applications have been
>>>>>> designed as independent components to make them more reusable and because
>>>>>> they were designed to be a set of reusable and generic artifacts, each of
>>>>>> them based on a specific domain of the data model (order, party, product
>>>>>> etc...).
>>>>>> They were not intended to be ready to be used out of the box; they were
>>>>>> not intended to implement complete ERP workflows (mostly all complete real
>>>>>> World workflows encompass several domains) but rather to provide some
>>>>>> common artifacts (screens, forms, basic business rules) to facilitate the
>>>>>> implementation of custom applications.
>>>>>> However over the years, they have been implemented to be used as being
>>>>>> part of the same big suite of ERP applications: i.e. the building blocks of
>>>>>> a specific instance of an ERP system.
>>>>>> Some (parts) of them have become "ready to be used" out of the box (for
>>>>>> certain specific business models) by implementing more specific workflows
>>>>>> (based on some real World requirements coming from companies): because of
>>>>>> the fact that there was not a central design and coordination (which
>>>>>> industry/business to implement etc...) and because for the same task
>>>>>> (shipping, receiving etc...) there are thousands of different valid
>>>>>> worflows we have now several workflows in OFBiz that implement similar
>>>>>> features but in different alternative ways.
>>>>>> It is off topic here to say if this is good (the company user can
>>>>>> choose between a series of choices based on the nature of its business and
>>>>>> then customize/clean/complete them) or bad (a lot of duplicated code, the
>>>>>> applications seem to deal with everything but they are not really really
>>>>>> good for anything): however it is a reality that the applications are now
>>>>>> more a suite of ERP application (one application) rather than reusable
>>>>>> generic artifacts that can be plugged together.
>>>>>> In fact the OFBiz Applications are now a set of OFBiz components that
>>>>>> are strictly interdependent at several layers (data model, service, ui).
>>>>>>
>>>>>> In their current status I believe that it would be better to merge them
>>>>>> into one big component, the "Apache OFBiz ERP" (or a better name).
>>>>>> The component will contain:
>>>>>> * the complete data model for the OFBiz application
>>>>>> * all the services (Java, Minilang)
>>>>>> * all data
>>>>>> * one web application (merged from the existing ones); even if
>>>>>> initially we could do this in steps and keep them separated as they are now
>>>>>> but under the same component
>>>>>> * one aggregated and consolidated set of ui labels
>>>>>>
>>>>>> Even in one component we will have several mechanisms to categorize our
>>>>>> artifacts (file names, folders) even if I would suggest to rethink them
>>>>>> based on new rules (and only if we need the categorization).
>>>>>> We could merge a lot of files (data preparation scripts, screen
>>>>>> definitions, service definitions etc...) to make them more consistent. We
>>>>>> would also resolve some of the issues with inter-application links and
>>>>>> navigation.
>>>>>> I am pretty sure that we could end up with less code and easier to
>>>>>> organize and maintain.
>>>>>>
>>>>>> It will also be more practical to reuse this component and extend it
>>>>>> from an external hot deploy component: you will have to extend one webapp
>>>>>> and then reuse from the official component what you like.
>>>>>>
>>>>>> This is just the rough ideas and there could be some variants to it: we
>>>>>> could isolate all the data model and services into one component and all
>>>>>> the applications (ui, screens, controllers, data prep scripts and
>>>>>> templates) into another one. etc. etc. etc...
>>>>>>
>>>>>> It is a lot of work but we are a big community and we like to keep us
>>>>>> busy.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>
> -- Nicolas MALIN
> Consultant
> Tél : [phone]
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : [phone]
> Site : http://www.librenberry.net/

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Olivier.heintz]

Hi,

I'm a ERP modularity Fan,

My ideal ERP would be a Kernel, smallest as possible but with all which
is common to all possible business applications,
  - Technical Framework (only on technical choice by domain)
  - Common Data model,  Entities and fields
  - Common Services
  - Common User interface
  - and whatever is detailled in
(https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision)

And a lot of "Component" (or addons or pluggin or functionality or ...)
which are easily installable (dependency management) to have OOTB ready
to use applications.

With that, Company or Community could propose some OFBiz "Distribution"


Since I have contributed (2003/2004) to OFBiz I'm convinced OFBiz
project can become the ERP I dream about :-). Every last Jacoppo (and
answered) mail threads are very good questions-reflexions to define the
road to get it ;-)

I try to make short answer to each thread to be more readable, and tried
to answer mail by mail to be able to be more precise.
This mail is only a introduction before the next 4 mails.



PS: I'm currently finishing a lot of contributions about portlet
management and ofbiz screen migration to portlet, first proposal will be
proposed next week


Le 15/03/2012 10:20, Nicolas Malin a écrit :

> Hi,
>
> At this time, applications components embedded functional framework
> and business oriented (massively B2C) and aren't user friendly.
> I possible solution will be have a dedicate application components for
> only Consultant or high level user that contains only the functional
> framework (with business process cleaned) and for end user an oriented
> business components
>
> Exemple :
>
> application /
>         content
>         humanres
>         manufacturing
>         marketing
>         order
>         party
>         product
>         workeffort
>
> specialpurpose :
>        cms
>        edm
>        ecommerce
>        order-b2b
>        crm-b2b
>        ...
>
> The business components contains (in a beautiful world) only business
> service process and simplified screen.
> We work with Apache OFBiz on hight parameter ERP  with dynamic (by
> jquery through screen engine) reusable screen based on portlet and
> portal page. Own idea is, the application components give a portlets
> list that business components use to configure their portal page.
>
> I'm not a modularity fan. For the technical framework, is great but
> I'm much more mixed to use on functional framework. Integration
> problem will not resolve easily.
>
> Nicolas
>
> Le 14/03/2012 23:04, Tom Burns a écrit :
>> Adrian / Jacopo
>>
>> While thinking about a refactoring the OFBiz Architecture you
>> may want to look at http://www.aosabook.org/en/intro.html. The book
>> is all
>> about Open Source architecture. In particular see the chapter on
>> Eclipse, the
>> ultimate open source component framework, Eclipse is the perfect
>> environment to
>> implement Adrian's ambitious vision.
>>   However the most pressing problem in OFBiz, given the
>> available resources, is not the architecture, rearranging the
>> components or refactoring
>> of what in Moque would be the Core / Mantel (i.e. a scripting
>> framework etc.).
>>   Rather the problem, as your most recent post to this thread
>> suggest, is the short comings in the OFBiz Crust. OOB the user facing
>> applications are difficult to understand, quirky and do not support
>> needed business
>> requirements. Just ask yourself would you go into a meeting with
>> Steve Jobs ghost
>> with these applications?
>>   On the OFBiz home page "What is Apache OFBiz" the
>> focus is clearly ERP. The bullet points advertise OOB application
>> functionality. The business applications should be easy to use,
>> robust, and well
>> documented. This will require more attention to business requirements,
>> providing a consistent set of defined services, adherence to
>> documented UI best
>> practices and well written and better presented user help.
>>   All of this is possible without doing more additional work
>> on the Core / Mantel.
>>   I would be happy to contribute to an effort to improve the
>> user facing applications if there is support from the committers.
>>   I see these applications as falling into two categories. Applications
>> that are common to most businesses and domain specific applications.
>> This
>> follows the pattern laid out in the two DMR Books. The former, more
>> general,
>> category should get the most attention. Those applications include:
>> Common Business - Requirements common to most businesses
>>   Accounting
>>   Human Resources
>>   Marketing
>>   Work Effort
>>   Reporting
>>   Document Management
>>   E-Commerce
>>   Others to be
>> identified
>>   I would like to start with Human Resources. Is anyone interested?
>>
>> Tom
>>
>>
>>
>> ________________________________
>>   From: Pierre Smits<[hidden email]>
>> To: [hidden email]
>> Sent: Wednesday, March 14, 2012 5:53 PM
>> Subject: Re: Rethinking the structure of the OFBiz Applications
>> Components
>>
>> Hi Adrian,
>>
>> Could you list the applications you comment out in your production
>> implementations? I think that would help creating insight.
>>
>> Regards,
>>
>> Pierre
>>
>> Op 14 maart 2012 18:33 schreef Adrian Crum<
>> [hidden email]>  het volgende:
>>
>>> Understood.
>>>
>>> As a service provider, I regularly comment out unused applications and
>>> build hot-deploy components to replace OOTB OFBiz components. I
>>> override
>>> service definitions, redefine entity definitions, etc - all in an
>>> effort to
>>> take what's good in OFBiz, and replace what's not-so-good. I seem to be
>>> doing a lot more of it lately - mostly due to components being added
>>> that
>>> break every other component. At least with a component approach,
>>> that sort
>>> of thing can be isolated and dealt with.
>>>
>>> -Adrian
>>>
>>>
>>> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
>>>
>>>> Thank you Adrian.
>>>>
>>>> Just to clarify that I was not talking about the architecture of the
>>>> framework (topic for another day) but only for the layout of the
>>>> applications and it is not based on what I think it is best in
>>>> general but
>>>> instead about what I think it is best to represent what we have
>>>> right now:
>>>> what we have right now is *one* big application (made of mostly all
>>>> the
>>>> components under the "applications" folder) that is split into
>>>> chunks (the
>>>> components) where each chunk is not built to be used alone.
>>>> I would be really interested to know from the users of the
>>>> "applications"
>>>> how many of them are removing (or not deploying) the components
>>>> they do not
>>>> need in their business.
>>>>
>>>> All in all I am trying to better represent (in a more convenient,
>>>> cheaper, easier to maintain way) what we already have, not to
>>>> suggest how
>>>> the perfect application built on OFBiz should be. The approach that
>>>> you are
>>>> suggesting on the other hand, that is inspiring, implies a complete
>>>> refactoring and redesign (also in terms of features) of the
>>>> applications.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>>>>
>>>>    That approach sounds very monolithic, and I tend to avoid
>>>> monoliths.
>>>>> I gave this subject a lot of thought about a year ago when I was
>>>>> working
>>>>> on a vision for a new framework (https://cwiki.apache.org/**
>>>>> confluence/display/OFBADMIN/**Another+Framework+Vision<https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision>).
>>>>>
>>>>> In particular, I was trying to devise a way for us to build a new
>>>>> architecture for OFBiz out of well-defined and self-contained
>>>>> parts - with
>>>>> the ultimate goal of using OSGI to connect them all together.
>>>>>
>>>>> That goal led to only one pattern that seemed to work: Hub-and-spoke.
>>>>> Hubs can be suspended, replaced, and restarted without too much
>>>>> disruption
>>>>> because they affect only the spokes connected to them.
>>>>>
>>>>> It sounds like what you're proposing is a layered pattern - like a
>>>>> wall
>>>>> built up of many bricks, but with an all-covering capstone on top.
>>>>>
>>>>> I don't have a strong opinion on which approach is best, but I
>>>>> tend to
>>>>> favor modularity.
>>>>>
>>>>> The discussion is worthwhile, and I appreciate you starting it.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>>>>
>>>>>> In the eraly days of the project, the OFBiz applications have been
>>>>>> designed as independent components to make them more reusable and
>>>>>> because
>>>>>> they were designed to be a set of reusable and generic artifacts,
>>>>>> each of
>>>>>> them based on a specific domain of the data model (order, party,
>>>>>> product
>>>>>> etc...).
>>>>>> They were not intended to be ready to be used out of the box;
>>>>>> they were
>>>>>> not intended to implement complete ERP workflows (mostly all
>>>>>> complete real
>>>>>> World workflows encompass several domains) but rather to provide
>>>>>> some
>>>>>> common artifacts (screens, forms, basic business rules) to
>>>>>> facilitate the
>>>>>> implementation of custom applications.
>>>>>> However over the years, they have been implemented to be used as
>>>>>> being
>>>>>> part of the same big suite of ERP applications: i.e. the building
>>>>>> blocks of
>>>>>> a specific instance of an ERP system.
>>>>>> Some (parts) of them have become "ready to be used" out of the
>>>>>> box (for
>>>>>> certain specific business models) by implementing more specific
>>>>>> workflows
>>>>>> (based on some real World requirements coming from companies):
>>>>>> because of
>>>>>> the fact that there was not a central design and coordination (which
>>>>>> industry/business to implement etc...) and because for the same task
>>>>>> (shipping, receiving etc...) there are thousands of different valid
>>>>>> worflows we have now several workflows in OFBiz that implement
>>>>>> similar
>>>>>> features but in different alternative ways.
>>>>>> It is off topic here to say if this is good (the company user can
>>>>>> choose between a series of choices based on the nature of its
>>>>>> business and
>>>>>> then customize/clean/complete them) or bad (a lot of duplicated
>>>>>> code, the
>>>>>> applications seem to deal with everything but they are not really
>>>>>> really
>>>>>> good for anything): however it is a reality that the applications
>>>>>> are now
>>>>>> more a suite of ERP application (one application) rather than
>>>>>> reusable
>>>>>> generic artifacts that can be plugged together.
>>>>>> In fact the OFBiz Applications are now a set of OFBiz components
>>>>>> that
>>>>>> are strictly interdependent at several layers (data model,
>>>>>> service, ui).
>>>>>>
>>>>>> In their current status I believe that it would be better to
>>>>>> merge them
>>>>>> into one big component, the "Apache OFBiz ERP" (or a better name).
>>>>>> The component will contain:
>>>>>> * the complete data model for the OFBiz application
>>>>>> * all the services (Java, Minilang)
>>>>>> * all data
>>>>>> * one web application (merged from the existing ones); even if
>>>>>> initially we could do this in steps and keep them separated as
>>>>>> they are now
>>>>>> but under the same component
>>>>>> * one aggregated and consolidated set of ui labels
>>>>>>
>>>>>> Even in one component we will have several mechanisms to
>>>>>> categorize our
>>>>>> artifacts (file names, folders) even if I would suggest to
>>>>>> rethink them
>>>>>> based on new rules (and only if we need the categorization).
>>>>>> We could merge a lot of files (data preparation scripts, screen
>>>>>> definitions, service definitions etc...) to make them more
>>>>>> consistent. We
>>>>>> would also resolve some of the issues with inter-application
>>>>>> links and
>>>>>> navigation.
>>>>>> I am pretty sure that we could end up with less code and easier to
>>>>>> organize and maintain.
>>>>>>
>>>>>> It will also be more practical to reuse this component and extend it
>>>>>> from an external hot deploy component: you will have to extend
>>>>>> one webapp
>>>>>> and then reuse from the official component what you like.
>>>>>>
>>>>>> This is just the rough ideas and there could be some variants to
>>>>>> it: we
>>>>>> could isolate all the data model and services into one component
>>>>>> and all
>>>>>> the applications (ui, screens, controllers, data prep scripts and
>>>>>> templates) into another one. etc. etc. etc...
>>>>>>
>>>>>> It is a lot of work but we are a big community and we like to
>>>>>> keep us
>>>>>> busy.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>
>

[Olivier.heintz]

comments are in-line

Le 14/03/2012 18:22, Jacopo Cappellato a écrit :
> Thank you Adrian.
>
> Just to clarify that I was not talking about the architecture of the framework (topic for another day) but only for the layout of the applications and it is not based on what I think it is best in general but instead about what I think it is best to represent what we have right now: what we have right now is *one* big application (made of mostly all the components under the "applications" folder) that is split into chunks (the components) where each chunk is not built to be used alone.
There is the current situation and the application framework we want.
For the future Ofbiz application Kernel, it seems more clear to have
only one component.
> I would be really interested to know from the users of the "applications" how many of them are removing (or not deploying) the components they do not need in their business.
Clearly, the first release can be done with very very restrictive
choices, only those which are never removed (always deployed), cleaning
up to entity field level.
> All in all I am trying to better represent (in a more convenient, cheaper, easier to maintain way) what we already have, not to suggest how the perfect application built on OFBiz should be. The approach that you are suggesting on the other hand, that is inspiring, implies a complete refactoring and redesign (also in terms of features) of the applications.
First step is vision and design, second step is how to aggregate brick.
Currently there are some best practices in OFBiz to define how to do
that, maybe it's necessary to define more, for example how to extend
existing scripts.
One important point is to define the correct brick size. In my opinion,
business usage is clearly the main criteria, if a part of a brick can be
used for one usage and another part for another usage, it should be
separated in two bricks, even if one depend from the other.

The brick install process should manage dependencies.

> Jacopo
>
> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>
>> That approach sounds very monolithic, and I tend to avoid monoliths.
>>
>> I gave this subject a lot of thought about a year ago when I was working on a vision for a new framework (https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision). In particular, I was trying to devise a way for us to build a new architecture for OFBiz out of well-defined and self-contained parts - with the ultimate goal of using OSGI to connect them all together.
>>
>> That goal led to only one pattern that seemed to work: Hub-and-spoke. Hubs can be suspended, replaced, and restarted without too much disruption because they affect only the spokes connected to them.
>>
>> It sounds like what you're proposing is a layered pattern - like a wall built up of many bricks, but with an all-covering capstone on top.
>>
>> I don't have a strong opinion on which approach is best, but I tend to favor modularity.
>>
>> The discussion is worthwhile, and I appreciate you starting it.
>>
>> -Adrian
>>
>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>> In the eraly days of the project, the OFBiz applications have been designed as independent components to make them more reusable and because they were designed to be a set of reusable and generic artifacts, each of them based on a specific domain of the data model (order, party, product etc...).
>>> They were not intended to be ready to be used out of the box; they were not intended to implement complete ERP workflows (mostly all complete real World workflows encompass several domains) but rather to provide some common artifacts (screens, forms, basic business rules) to facilitate the implementation of custom applications.
>>> However over the years, they have been implemented to be used as being part of the same big suite of ERP applications: i.e. the building blocks of a specific instance of an ERP system.
>>> Some (parts) of them have become "ready to be used" out of the box (for certain specific business models) by implementing more specific workflows (based on some real World requirements coming from companies): because of the fact that there was not a central design and coordination (which industry/business to implement etc...) and because for the same task (shipping, receiving etc...) there are thousands of different valid worflows we have now several workflows in OFBiz that implement similar features but in different alternative ways.
>>> It is off topic here to say if this is good (the company user can choose between a series of choices based on the nature of its business and then customize/clean/complete them) or bad (a lot of duplicated code, the applications seem to deal with everything but they are not really really good for anything): however it is a reality that the applications are now more a suite of ERP application (one application) rather than reusable generic artifacts that can be plugged together.
>>> In fact the OFBiz Applications are now a set of OFBiz components that are strictly interdependent at several layers (data model, service, ui).
>>>
>>> In their current status I believe that it would be better to merge them into one big component, the "Apache OFBiz ERP" (or a better name).
>>> The component will contain:
>>> * the complete data model for the OFBiz application
>>> * all the services (Java, Minilang)
>>> * all data
>>> * one web application (merged from the existing ones); even if initially we could do this in steps and keep them separated as they are now but under the same component
>>> * one aggregated and consolidated set of ui labels
>>>
>>> Even in one component we will have several mechanisms to categorize our artifacts (file names, folders) even if I would suggest to rethink them based on new rules (and only if we need the categorization).
>>> We could merge a lot of files (data preparation scripts, screen definitions, service definitions etc...) to make them more consistent. We would also resolve some of the issues with inter-application links and navigation.
>>> I am pretty sure that we could end up with less code and easier to organize and maintain.
>>>
>>> It will also be more practical to reuse this component and extend it from an external hot deploy component: you will have to extend one webapp and then reuse from the official component what you like.
>>>
>>> This is just the rough ideas and there could be some variants to it: we could isolate all the data model and services into one component and all the applications (ui, screens, controllers, data prep scripts and templates) into another one. etc. etc. etc...
>>>
>>> It is a lot of work but we are a big community and we like to keep us busy.
>>>
>>> What do you think?
>>>
>>> Jacopo
>>>
>

[Olivier.heintz]

comments are in-line

Le 14/03/2012 19:34, Jacopo Cappellato a écrit :

> On Mar 14, 2012, at 6:33 PM, Adrian Crum wrote:
>
>> Understood.
>>
>> As a service provider, I regularly comment out unused applications
> I would be interested to know what are the applications under the "applications" folder that you comment out: do you you mean web applications, not component
>
>> and build hot-deploy components to replace OOTB OFBiz components.
> we (the company I work for) do the same extensively
>
>> I override service definitions, redefine entity definitions, etc - all in an effort to take what's good in OFBiz, and replace what's not-so-good
> we do the same; to take the good and also to add custom features not well suited for the general purpose applications
>
>
>> . I seem to be doing a lot more of it lately
> This is the approach we follow since a long time and it has proven to be effective.
>
>> - mostly due to components being added that break every other component.
> this is another sad topic :-)

Continuous Integration with functional test is the only solution ;-)
>> At least with a component approach, that sort of thing can be isolated and dealt with.
> I don't see how the tasks mentioned above are easier with the applications split into components.
for a business analyst point of view, it's easier to define the
component boundaries and functional tests for one component than for a
full application, so easier to define a Continuous-Integration Job to
check if it's always ok.
For developer it's easier to make correction in a well defined domain,
not too large.

> Jacopo
>
>> -Adrian
>>
>> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
>>> Thank you Adrian.
>>>
>>> Just to clarify that I was not talking about the architecture of the framework (topic for another day) but only for the layout of the applications and it is not based on what I think it is best in general but instead about what I think it is best to represent what we have right now: what we have right now is *one* big application (made of mostly all the components under the "applications" folder) that is split into chunks (the components) where each chunk is not built to be used alone.
>>> I would be really interested to know from the users of the "applications" how many of them are removing (or not deploying) the components they do not need in their business.
>>>
>>> All in all I am trying to better represent (in a more convenient, cheaper, easier to maintain way) what we already have, not to suggest how the perfect application built on OFBiz should be. The approach that you are suggesting on the other hand, that is inspiring, implies a complete refactoring and redesign (also in terms of features) of the applications.
>>>
>>> Jacopo
>>>
>>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>>>
>>>> That approach sounds very monolithic, and I tend to avoid monoliths.
>>>>
>>>> I gave this subject a lot of thought about a year ago when I was working on a vision for a new framework (https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision). In particular, I was trying to devise a way for us to build a new architecture for OFBiz out of well-defined and self-contained parts - with the ultimate goal of using OSGI to connect them all together.
>>>>
>>>> That goal led to only one pattern that seemed to work: Hub-and-spoke. Hubs can be suspended, replaced, and restarted without too much disruption because they affect only the spokes connected to them.
>>>>
>>>> It sounds like what you're proposing is a layered pattern - like a wall built up of many bricks, but with an all-covering capstone on top.
>>>>
>>>> I don't have a strong opinion on which approach is best, but I tend to favor modularity.
>>>>
>>>> The discussion is worthwhile, and I appreciate you starting it.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>>>> In the eraly days of the project, the OFBiz applications have been designed as independent components to make them more reusable and because they were designed to be a set of reusable and generic artifacts, each of them based on a specific domain of the data model (order, party, product etc...).
>>>>> They were not intended to be ready to be used out of the box; they were not intended to implement complete ERP workflows (mostly all complete real World workflows encompass several domains) but rather to provide some common artifacts (screens, forms, basic business rules) to facilitate the implementation of custom applications.
>>>>> However over the years, they have been implemented to be used as being part of the same big suite of ERP applications: i.e. the building blocks of a specific instance of an ERP system.
>>>>> Some (parts) of them have become "ready to be used" out of the box (for certain specific business models) by implementing more specific workflows (based on some real World requirements coming from companies): because of the fact that there was not a central design and coordination (which industry/business to implement etc...) and because for the same task (shipping, receiving etc...) there are thousands of different valid worflows we have now several workflows in OFBiz that implement similar features but in different alternative ways.
>>>>> It is off topic here to say if this is good (the company user can choose between a series of choices based on the nature of its business and then customize/clean/complete them) or bad (a lot of duplicated code, the applications seem to deal with everything but they are not really really good for anything): however it is a reality that the applications are now more a suite of ERP application (one application) rather than reusable generic artifacts that can be plugged together.
>>>>> In fact the OFBiz Applications are now a set of OFBiz components that are strictly interdependent at several layers (data model, service, ui).
>>>>>
>>>>> In their current status I believe that it would be better to merge them into one big component, the "Apache OFBiz ERP" (or a better name).
>>>>> The component will contain:
>>>>> * the complete data model for the OFBiz application
>>>>> * all the services (Java, Minilang)
>>>>> * all data
>>>>> * one web application (merged from the existing ones); even if initially we could do this in steps and keep them separated as they are now but under the same component
>>>>> * one aggregated and consolidated set of ui labels
>>>>>
>>>>> Even in one component we will have several mechanisms to categorize our artifacts (file names, folders) even if I would suggest to rethink them based on new rules (and only if we need the categorization).
>>>>> We could merge a lot of files (data preparation scripts, screen definitions, service definitions etc...) to make them more consistent. We would also resolve some of the issues with inter-application links and navigation.
>>>>> I am pretty sure that we could end up with less code and easier to organize and maintain.
>>>>>
>>>>> It will also be more practical to reuse this component and extend it from an external hot deploy component: you will have to extend one webapp and then reuse from the official component what you like.
>>>>>
>>>>> This is just the rough ideas and there could be some variants to it: we could isolate all the data model and services into one component and all the applications (ui, screens, controllers, data prep scripts and templates) into another one. etc. etc. etc...
>>>>>
>>>>> It is a lot of work but we are a big community and we like to keep us busy.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Jacopo
>>>>>
>

[Olivier.heintz]

comments are in-line

Le 14/03/2012 23:04, Tom Burns a écrit :

> Adrian / Jacopo
>
> While thinking about a refactoring the OFBiz Architecture you
> may want to look at http://www.aosabook.org/en/intro.html. The book is all
> about Open Source architecture. In particular see the chapter on Eclipse, the
> ultimate open source component framework, Eclipse is the perfect environment to
> implement Adrian's ambitious vision.
>  
> However the most pressing problem in OFBiz, given the
> available resources, is not the architecture, rearranging the components or refactoring
> of what in Moque would be the Core / Mantel (i.e. a scripting framework etc.).
>  
> Rather the problem, as your most recent post to this thread
> suggest, is the short comings in the OFBiz Crust. OOB the user facing
> applications are difficult to understand, quirky and do not support needed business
> requirements. Just ask yourself would you go into a meeting with Steve Jobs ghost
> with these applications?
>  
> On the OFBiz home page "What is Apache OFBiz" the
> focus is clearly ERP. The bullet points advertise OOB application
> functionality. The business applications should be easy to use, robust, and well
> documented. This will require more attention to business requirements,
> providing a consistent set of defined services, adherence to documented UI best
> practices and well written and better presented user help.
>  
> All of this is possible without doing more additional work
> on the Core / Mantel.
>  
> I would be happy to contribute to an effort to improve the
> user facing applications if there is support from the committers.

For user interface, it's necessary to be modular and configurable. In
OFBiz, portlet and portalPage seems to be a good answer (even if it's
necessary to enhance some mechanisms).
We (the company I work for) have enhance portlet management and migrate
some OFBiz screens to portlets (~30%) and use it on multiple customer
projects. These customers all seems to have a good feeling with this
"new" user interface.
I am currently finishing the functional and code review on portlet
management enhancement to be able to propose it to OFBiz Community. I
hope to propose first mail and Jira next week.
When these enhancements will be correct to be integrated in OFBiz. I
will be able to propose portlets (which are coming from screen migration).

I hope it will be an important step in a user facing interface improvement.

Next step will be to migrate all screens which are necessary to migrate. ;-)

>
>  
> I see these applications as falling into two categories. Applications
> that are common to most businesses and domain specific applications. This
> follows the pattern laid out in the two DMR Books. The former, more general,
> category should get the most attention. Those applications include:
> Common Business - Requirements common to most businesses
>   Accounting
>   Human Resources
>   Marketing
>   Work Effort
>   Reporting
>   Document Management
>   E-Commerce
>   Others to be
> identified
>   I would like to start with Human Resources. Is anyone interested?
>
> Tom
>
>
>
> ________________________________
>   From: Pierre Smits<[hidden email]>
> To: [hidden email]
> Sent: Wednesday, March 14, 2012 5:53 PM
> Subject: Re: Rethinking the structure of the OFBiz Applications Components
>
> Hi Adrian,
>
> Could you list the applications you comment out in your production
> implementations? I think that would help creating insight.
>
> Regards,
>
> Pierre
>
> Op 14 maart 2012 18:33 schreef Adrian Crum<
> [hidden email]>  het volgende:
>
>> Understood.
>>
>> As a service provider, I regularly comment out unused applications and
>> build hot-deploy components to replace OOTB OFBiz components. I override
>> service definitions, redefine entity definitions, etc - all in an effort to
>> take what's good in OFBiz, and replace what's not-so-good. I seem to be
>> doing a lot more of it lately - mostly due to components being added that
>> break every other component. At least with a component approach, that sort
>> of thing can be isolated and dealt with.
>>
>> -Adrian
>>
>>
>> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
>>
>>> Thank you Adrian.
>>>
>>> Just to clarify that I was not talking about the architecture of the
>>> framework (topic for another day) but only for the layout of the
>>> applications and it is not based on what I think it is best in general but
>>> instead about what I think it is best to represent what we have right now:
>>> what we have right now is *one* big application (made of mostly all the
>>> components under the "applications" folder) that is split into chunks (the
>>> components) where each chunk is not built to be used alone.
>>> I would be really interested to know from the users of the "applications"
>>> how many of them are removing (or not deploying) the components they do not
>>> need in their business.
>>>
>>> All in all I am trying to better represent (in a more convenient,
>>> cheaper, easier to maintain way) what we already have, not to suggest how
>>> the perfect application built on OFBiz should be. The approach that you are
>>> suggesting on the other hand, that is inspiring, implies a complete
>>> refactoring and redesign (also in terms of features) of the applications.
>>>
>>> Jacopo
>>>
>>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>>>
>>>    That approach sounds very monolithic, and I tend to avoid monoliths.
>>>> I gave this subject a lot of thought about a year ago when I was working
>>>> on a vision for a new framework (https://cwiki.apache.org/**
>>>> confluence/display/OFBADMIN/**Another+Framework+Vision<https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision>).
>>>> In particular, I was trying to devise a way for us to build a new
>>>> architecture for OFBiz out of well-defined and self-contained parts - with
>>>> the ultimate goal of using OSGI to connect them all together.
>>>>
>>>> That goal led to only one pattern that seemed to work: Hub-and-spoke.
>>>> Hubs can be suspended, replaced, and restarted without too much disruption
>>>> because they affect only the spokes connected to them.
>>>>
>>>> It sounds like what you're proposing is a layered pattern - like a wall
>>>> built up of many bricks, but with an all-covering capstone on top.
>>>>
>>>> I don't have a strong opinion on which approach is best, but I tend to
>>>> favor modularity.
>>>>
>>>> The discussion is worthwhile, and I appreciate you starting it.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>>>
>>>>> In the eraly days of the project, the OFBiz applications have been
>>>>> designed as independent components to make them more reusable and because
>>>>> they were designed to be a set of reusable and generic artifacts, each of
>>>>> them based on a specific domain of the data model (order, party, product
>>>>> etc...).
>>>>> They were not intended to be ready to be used out of the box; they were
>>>>> not intended to implement complete ERP workflows (mostly all complete real
>>>>> World workflows encompass several domains) but rather to provide some
>>>>> common artifacts (screens, forms, basic business rules) to facilitate the
>>>>> implementation of custom applications.
>>>>> However over the years, they have been implemented to be used as being
>>>>> part of the same big suite of ERP applications: i.e. the building blocks of
>>>>> a specific instance of an ERP system.
>>>>> Some (parts) of them have become "ready to be used" out of the box (for
>>>>> certain specific business models) by implementing more specific workflows
>>>>> (based on some real World requirements coming from companies): because of
>>>>> the fact that there was not a central design and coordination (which
>>>>> industry/business to implement etc...) and because for the same task
>>>>> (shipping, receiving etc...) there are thousands of different valid
>>>>> worflows we have now several workflows in OFBiz that implement similar
>>>>> features but in different alternative ways.
>>>>> It is off topic here to say if this is good (the company user can
>>>>> choose between a series of choices based on the nature of its business and
>>>>> then customize/clean/complete them) or bad (a lot of duplicated code, the
>>>>> applications seem to deal with everything but they are not really really
>>>>> good for anything): however it is a reality that the applications are now
>>>>> more a suite of ERP application (one application) rather than reusable
>>>>> generic artifacts that can be plugged together.
>>>>> In fact the OFBiz Applications are now a set of OFBiz components that
>>>>> are strictly interdependent at several layers (data model, service, ui).
>>>>>
>>>>> In their current status I believe that it would be better to merge them
>>>>> into one big component, the "Apache OFBiz ERP" (or a better name).
>>>>> The component will contain:
>>>>> * the complete data model for the OFBiz application
>>>>> * all the services (Java, Minilang)
>>>>> * all data
>>>>> * one web application (merged from the existing ones); even if
>>>>> initially we could do this in steps and keep them separated as they are now
>>>>> but under the same component
>>>>> * one aggregated and consolidated set of ui labels
>>>>>
>>>>> Even in one component we will have several mechanisms to categorize our
>>>>> artifacts (file names, folders) even if I would suggest to rethink them
>>>>> based on new rules (and only if we need the categorization).
>>>>> We could merge a lot of files (data preparation scripts, screen
>>>>> definitions, service definitions etc...) to make them more consistent. We
>>>>> would also resolve some of the issues with inter-application links and
>>>>> navigation.
>>>>> I am pretty sure that we could end up with less code and easier to
>>>>> organize and maintain.
>>>>>
>>>>> It will also be more practical to reuse this component and extend it
>>>>> from an external hot deploy component: you will have to extend one webapp
>>>>> and then reuse from the official component what you like.
>>>>>
>>>>> This is just the rough ideas and there could be some variants to it: we
>>>>> could isolate all the data model and services into one component and all
>>>>> the applications (ui, screens, controllers, data prep scripts and
>>>>> templates) into another one. etc. etc. etc...
>>>>>
>>>>> It is a lot of work but we are a big community and we like to keep us
>>>>> busy.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Jacopo
>>>>>
>>>>>

[Jacopo Cappellato-4]

Thanks for all the comments; but I actually didn't want to fall again in the never ending story about what we think the perfect  applications should look like: it is way too abstract topic, there are so many different opinions and it has been discussed in the past so many times without finding a common ground; actually I think that the reason is because no one is really interested in understanding what others are suggesting because everyone is convinced that his personal idea is perfect (and it doesn't care if there is no proof for this).
In fact I now understand that the subject of this thread is misleading: I didn't want to pull the trigger of a collective brainstorming session but instead reflect on the current status of the applications (i.e. the components under applications/) and suggest a better way to organize them based on their *current* status.
All the feedback I got was about what each of you think the applications should be... interesting but off topic because what you are all talking about is a complete rewriting (that must be done after a serious requirement gathering, analysis and architecture design)... nice to chat about this as well but definitely something for the future.

All I did is simply analyzing what we have *now* in the applications folder and I have proposed a solution to better manage the stuff we have (good or bad). None of the feedback I got so far is showing that it is a bad idea.

Jacopo


On Mar 16, 2012, at 2:05 PM, Nicolas Malin wrote:

> Le 15/03/2012 19:01, Tom Burns a écrit :
>> Nicolas,
>>
>> I think your dream OFBiz development environment would be something like what Salesforce.com offers.
> Yes it's a dream, in reality these solution isn't viable to create an generic ERP has Apache OFBiz.If you scratch, application are so business oriented, and functional structure miss. Quick write, quick drop :) as windev.
>> They have two tiers for developers - those that code and those that do not. It's a beautiful world!
> Code to code maybe, important is the reuse work. In technical is make easier, but on functional layers few developers happens to do it. And that is why I love OFBiz ;) . I can code with this aim !
>
> Nicolas
>
>> For those that do not there is powerful visual in the cloud on line development environment where you can create useful apps with db entities, forms, lists etc. using only GUI forms and wizards.
>>
>> No Java, No XML, No groovy, No ftl, No Mini-Language etc etc.
>>
>>
>> For coders they have their own java type language in an Eclipse app.Doesn't look like anything like that is on the radar for OFBiz but if it was available I'd bet it would satisfy a large percentage of the customization needs.
>>
>> Tom
>>
>>
>>
>> ________________________________
>>  From: Nicolas Malin<[hidden email]>
>> To: [hidden email]
>> Sent: Thursday, March 15, 2012 5:20 AM
>> Subject: Re: Rethinking the structure of the OFBiz Applications Components
>>
>> Hi,
>>
>> At this time, applications components embedded functional framework and business oriented (massively B2C) and aren't user friendly.
>> I possible solution will be have a dedicate application components for only Consultant or high level user that contains only the functional framework (with business process cleaned) and for end user an oriented business components
>>
>> Exemple :
>>
>> application /
>>         content
>>         humanres
>>         manufacturing
>>         marketing
>>         order
>>         party
>>         product
>>         workeffort
>>
>> specialpurpose :
>>        cms
>>        edm
>>        ecommerce
>>        order-b2b
>>        crm-b2b
>>        ...
>>
>> The business components contains (in a beautiful world) only business service process and simplified screen.
>> We work with Apache OFBiz on hight parameter ERP  with dynamic (by jquery through screen engine) reusable screen based on portlet and portal page. Own idea is, the application components give a portlets list that business components use to configure their portal page.
>>
>> I'm not a modularity fan. For the technical framework, is great but I'm much more mixed to use on functional framework. Integration problem will not resolve easily.
>>
>> Nicolas
>>
>> Le 14/03/2012 23:04, Tom Burns a écrit :
>>> Adrian / Jacopo
>>>
>>> While thinking about a refactoring the OFBiz Architecture you
>>> may want to look at http://www.aosabook.org/en/intro.html. The book is all
>>> about Open Source architecture. In particular see the chapter on Eclipse, the
>>> ultimate open source component framework, Eclipse is the perfect environment to
>>> implement Adrian's ambitious vision.
>>>    However the most pressing problem in OFBiz, given the
>>> available resources, is not the architecture, rearranging the components or refactoring
>>> of what in Moque would be the Core / Mantel (i.e. a scripting framework etc.).
>>>    Rather the problem, as your most recent post to this thread
>>> suggest, is the short comings in the OFBiz Crust. OOB the user facing
>>> applications are difficult to understand, quirky and do not support needed business
>>> requirements. Just ask yourself would you go into a meeting with Steve Jobs ghost
>>> with these applications?
>>>    On the OFBiz home page "What is Apache OFBiz" the
>>> focus is clearly ERP. The bullet points advertise OOB application
>>> functionality. The business applications should be easy to use, robust, and well
>>> documented. This will require more attention to business requirements,
>>> providing a consistent set of defined services, adherence to documented UI best
>>> practices and well written and better presented user help.
>>>    All of this is possible without doing more additional work
>>> on the Core / Mantel.
>>>    I would be happy to contribute to an effort to improve the
>>> user facing applications if there is support from the committers.
>>>    I see these applications as falling into two categories. Applications
>>> that are common to most businesses and domain specific applications. This
>>> follows the pattern laid out in the two DMR Books. The former, more general,
>>> category should get the most attention. Those applications include:
>>> Common Business - Requirements common to most businesses
>>>    Accounting
>>>    Human Resources
>>>    Marketing
>>>    Work Effort
>>>    Reporting
>>>    Document Management
>>>    E-Commerce
>>>    Others to be
>>> identified
>>>    I would like to start with Human Resources. Is anyone interested?
>>>
>>> Tom
>>>
>>>
>>>
>>> ________________________________
>>>    From: Pierre Smits<[hidden email]>
>>> To: [hidden email]
>>> Sent: Wednesday, March 14, 2012 5:53 PM
>>> Subject: Re: Rethinking the structure of the OFBiz Applications Components
>>>
>>> Hi Adrian,
>>>
>>> Could you list the applications you comment out in your production
>>> implementations? I think that would help creating insight.
>>>
>>> Regards,
>>>
>>> Pierre
>>>
>>> Op 14 maart 2012 18:33 schreef Adrian Crum<
>>> [hidden email]>   het volgende:
>>>
>>>> Understood.
>>>>
>>>> As a service provider, I regularly comment out unused applications and
>>>> build hot-deploy components to replace OOTB OFBiz components. I override
>>>> service definitions, redefine entity definitions, etc - all in an effort to
>>>> take what's good in OFBiz, and replace what's not-so-good. I seem to be
>>>> doing a lot more of it lately - mostly due to components being added that
>>>> break every other component. At least with a component approach, that sort
>>>> of thing can be isolated and dealt with.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
>>>>
>>>>> Thank you Adrian.
>>>>>
>>>>> Just to clarify that I was not talking about the architecture of the
>>>>> framework (topic for another day) but only for the layout of the
>>>>> applications and it is not based on what I think it is best in general but
>>>>> instead about what I think it is best to represent what we have right now:
>>>>> what we have right now is *one* big application (made of mostly all the
>>>>> components under the "applications" folder) that is split into chunks (the
>>>>> components) where each chunk is not built to be used alone.
>>>>> I would be really interested to know from the users of the "applications"
>>>>> how many of them are removing (or not deploying) the components they do not
>>>>> need in their business.
>>>>>
>>>>> All in all I am trying to better represent (in a more convenient,
>>>>> cheaper, easier to maintain way) what we already have, not to suggest how
>>>>> the perfect application built on OFBiz should be. The approach that you are
>>>>> suggesting on the other hand, that is inspiring, implies a complete
>>>>> refactoring and redesign (also in terms of features) of the applications.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
>>>>>
>>>>>     That approach sounds very monolithic, and I tend to avoid monoliths.
>>>>>> I gave this subject a lot of thought about a year ago when I was working
>>>>>> on a vision for a new framework (https://cwiki.apache.org/**
>>>>>> confluence/display/OFBADMIN/**Another+Framework+Vision<https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision>).
>>>>>> In particular, I was trying to devise a way for us to build a new
>>>>>> architecture for OFBiz out of well-defined and self-contained parts - with
>>>>>> the ultimate goal of using OSGI to connect them all together.
>>>>>>
>>>>>> That goal led to only one pattern that seemed to work: Hub-and-spoke.
>>>>>> Hubs can be suspended, replaced, and restarted without too much disruption
>>>>>> because they affect only the spokes connected to them.
>>>>>>
>>>>>> It sounds like what you're proposing is a layered pattern - like a wall
>>>>>> built up of many bricks, but with an all-covering capstone on top.
>>>>>>
>>>>>> I don't have a strong opinion on which approach is best, but I tend to
>>>>>> favor modularity.
>>>>>>
>>>>>> The discussion is worthwhile, and I appreciate you starting it.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
>>>>>>
>>>>>>> In the eraly days of the project, the OFBiz applications have been
>>>>>>> designed as independent components to make them more reusable and because
>>>>>>> they were designed to be a set of reusable and generic artifacts, each of
>>>>>>> them based on a specific domain of the data model (order, party, product
>>>>>>> etc...).
>>>>>>> They were not intended to be ready to be used out of the box; they were
>>>>>>> not intended to implement complete ERP workflows (mostly all complete real
>>>>>>> World workflows encompass several domains) but rather to provide some
>>>>>>> common artifacts (screens, forms, basic business rules) to facilitate the
>>>>>>> implementation of custom applications.
>>>>>>> However over the years, they have been implemented to be used as being
>>>>>>> part of the same big suite of ERP applications: i.e. the building blocks of
>>>>>>> a specific instance of an ERP system.
>>>>>>> Some (parts) of them have become "ready to be used" out of the box (for
>>>>>>> certain specific business models) by implementing more specific workflows
>>>>>>> (based on some real World requirements coming from companies): because of
>>>>>>> the fact that there was not a central design and coordination (which
>>>>>>> industry/business to implement etc...) and because for the same task
>>>>>>> (shipping, receiving etc...) there are thousands of different valid
>>>>>>> worflows we have now several workflows in OFBiz that implement similar
>>>>>>> features but in different alternative ways.
>>>>>>> It is off topic here to say if this is good (the company user can
>>>>>>> choose between a series of choices based on the nature of its business and
>>>>>>> then customize/clean/complete them) or bad (a lot of duplicated code, the
>>>>>>> applications seem to deal with everything but they are not really really
>>>>>>> good for anything): however it is a reality that the applications are now
>>>>>>> more a suite of ERP application (one application) rather than reusable
>>>>>>> generic artifacts that can be plugged together.
>>>>>>> In fact the OFBiz Applications are now a set of OFBiz components that
>>>>>>> are strictly interdependent at several layers (data model, service, ui).
>>>>>>>
>>>>>>> In their current status I believe that it would be better to merge them
>>>>>>> into one big component, the "Apache OFBiz ERP" (or a better name).
>>>>>>> The component will contain:
>>>>>>> * the complete data model for the OFBiz application
>>>>>>> * all the services (Java, Minilang)
>>>>>>> * all data
>>>>>>> * one web application (merged from the existing ones); even if
>>>>>>> initially we could do this in steps and keep them separated as they are now
>>>>>>> but under the same component
>>>>>>> * one aggregated and consolidated set of ui labels
>>>>>>>
>>>>>>> Even in one component we will have several mechanisms to categorize our
>>>>>>> artifacts (file names, folders) even if I would suggest to rethink them
>>>>>>> based on new rules (and only if we need the categorization).
>>>>>>> We could merge a lot of files (data preparation scripts, screen
>>>>>>> definitions, service definitions etc...) to make them more consistent. We
>>>>>>> would also resolve some of the issues with inter-application links and
>>>>>>> navigation.
>>>>>>> I am pretty sure that we could end up with less code and easier to
>>>>>>> organize and maintain.
>>>>>>>
>>>>>>> It will also be more practical to reuse this component and extend it
>>>>>>> from an external hot deploy component: you will have to extend one webapp
>>>>>>> and then reuse from the official component what you like.
>>>>>>>
>>>>>>> This is just the rough ideas and there could be some variants to it: we
>>>>>>> could isolate all the data model and services into one component and all
>>>>>>> the applications (ui, screens, controllers, data prep scripts and
>>>>>>> templates) into another one. etc. etc. etc...
>>>>>>>
>>>>>>> It is a lot of work but we are a big community and we like to keep us
>>>>>>> busy.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>
>>
>> -- Nicolas MALIN
>> Consultant
>> Tél : [phone]
>> Site projet : http://www.neogia.org/
>> -------
>> Société LibrenBerry
>> Tél : [phone]
>> Site : http://www.librenberry.net/
>
>
> --
> Nicolas MALIN
> Consultant
> Tél : [phone]
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : [phone]
> Site : http://www.librenberry.net/
>