Re: Move Application Entity Definitions to A Separate Component

2015-06-15 Thread Ron Wheeler 

On 14/06/2015 2:16 AM, Jacques Le Roux wrote:

Le 13/06/2015 14:12, Ron Wheeler a écrit :
a) I am not sure why applications/datamodel/entitidef/ could not be 
entitydef / since it is shorter and unambiguous and spells entity 
correctly.


Applications was suggested because there are underneath mechanisms to 
handle the specialised folders framework, applications, specialpurpose 
and hot-deploy (which is a confusing name, eg extensions would have 
been better)
Datamodel is a real unambiguous name, while entitydef is less (HTML 
entities? etc.: https://en.wikipedia.org/wiki/Entity), this is a moot 
point.

I meant locally unambiguous within the OFBiz source structure.


b) I thought that hot-deploy was for local customizations. 
"entitydef/..." are user contributed libraries that are part of the 
standard OFBiz project to support industry-specific or 
locale-specific requirements.


Jacopo's suggestion is straightforward. It's the 1st move we are 
currently discussing to agree on.  Your propositon is interesting but 
to avoid confusion should be discussed later, in another thread.
I am trying to avoid a short term solution that makes a long-term 
solution more difficult for no real reason. I am not sure how many 
specialized entity definitions are stting on shelves today that could be 
shared (either for free or as commercial offerings).


c) I am suggesting a structure that makes it easy for someone 
customizing their implementation. Take all the xml files under 
entitydef ( or entitydef/default or entity/basic) and overwrite them 
with the set of XML files suitable for the particular locale that you 
want such as entitydef/eCommerce/NAFTA to get the definitions that 
match an eCommerce site in North America US and Canada terminology 
and the extensions or modifications required to support an 
eCommerce-only OFBiz aimed at a North American clientele.
If the system integrator does further customization and wants to put 
their branding or  customer-specific overrides in hot-deploy at 
run-time to keep them separate from the XML files that come from 
OFBiz, that sounds like a good practice but is different from the 


How to realise you idea needs to be discussed (again separately). A 
new mechanism might need to be created. In OFBiz a last read entity 
definition overrides the previous . How to separate/aggregate is not 
obvious to me in your proposition. Did you think about optional entity 
extensions (defined using the extend-entity mechanism) which would not 
be activated OOTB but could be loaded by users when needed (Oops, you 
see I'm  already discussing your proposition)?
I was suggesting a scheme where the file names are identical but the 
files come from different paths so the run-time situation would have no 
duplication of file names but the files might come from different 
sources (accounting-entitymodel.xml from 
"entitydef/general/accounting-entitymodel.xml" being overwritten by 
"entitydef/general/UK/accounting-entitymodel.xml" in the case where the 
installation required the UK version of "accounting-entitymodel.xml"
This implies that all of the definitions in 
entitydef/general/UK/accounting-entitymodel.xml are also in 
entitydef/general/accounting-entitymodel.xml.


Ron


Jacques


shared library structure we are discussing.

Does that clarify my points?

Ron



On 12/06/2015 9:51 AM, Nicolas Malin wrote:
Ron I didn't understand why you want adding specialization directory 
directly on main component (like entitydef/general/UK/).


For me this information need to be set on the dedicate component in 
hot-deploy.


Nicolas

Le 12/06/2015 13:17, Ron Wheeler a écrit :
It would be nice to get the philosophy of the structure agreed at 
the beginning even if there is only one variant of 
accounting-entitymodel.xml .
It might prevent conflicts over the content of some of the files 
and encourage more contributors who are confident about how their 
definitions work but are unwilling to change someone else's working 
set of entities, to contribute their variants.


For example, I could  supply my idea of what the Canadian 
accounting-entitymodel.xml should contain without breaking 
something that others are using.


An alternative scheme that might be easier to use would be to 
structure the files as

entitydef/accounting-entitymodel.xml
entitydef/ecommerce-entitymodel.xml
entitydef/general/UK/accounting-entitymodel.xml
entitydef/general/UK/ecommerce-entitymodel.xml

I am not sure that adding applications/datamodel to the front adds 
any value

entitydef is pretty unambiguous.

Putting the variants first would mean that all of the default 
entity definitions are in one folder and general/UK would all be in 
another.
To get a complete set, copy everything from entitydef and then copy 
everything from entitydef/general/UK to get the overrides required 
t create the UK variant.


Ron

On 12/06/2015 2:39 AM, Jacques Le Roux wrote:

Le 11/06/2015 21:10, Ron Wheeler a écrit :
I would suggest adding other le

Re: Move Application Entity Definitions to A Separate Component

2015-06-14 Thread Jacques Le Roux 

Le 13/06/2015 14:12, Ron Wheeler a écrit :

a) I am not sure why applications/datamodel/entitidef/ could not be entitydef / 
since it is shorter and unambiguous and spells entity correctly.


Applications was suggested because there are underneath mechanisms to handle the specialised folders framework, applications, specialpurpose and 
hot-deploy (which is a confusing name, eg extensions would have been better)

Datamodel is a real unambiguous name, while entitydef is less (HTML entities? 
etc.: https://en.wikipedia.org/wiki/Entity), this is a moot point.

b) I thought that hot-deploy was for local customizations. "entitydef/..." are user contributed libraries that are part of the standard OFBiz 
project to support industry-specific or locale-specific requirements.


Jacopo's suggestion is straightforward. It's the 1st move we are currently discussing to agree on.  Your propositon is interesting but to avoid 
confusion should be discussed later, in another thread.


c) I am suggesting a structure that makes it easy for someone customizing their implementation. Take all the xml files under entitydef ( or 
entitydef/default or entity/basic) and overwrite them with the set of XML files suitable for the particular locale that you want such as 
entitydef/eCommerce/NAFTA to get the definitions that match an eCommerce site in North America US and Canada terminology and the extensions or 
modifications required to support an eCommerce-only OFBiz aimed at a North American clientele.
If the system integrator does further customization and wants to put their branding or  customer-specific overrides in hot-deploy at run-time to 
keep them separate from the XML files that come from OFBiz, that sounds like a good practice but is different from the 


How to realise you idea needs to be discussed (again separately). A new mechanism might need to be created. In OFBiz a last read entity definition 
overrides the previous . How to separate/aggregate is not obvious to me in your proposition. Did you think about optional entity extensions (defined 
using the extend-entity mechanism) which would not be activated OOTB but could be loaded by users when needed (Oops, you see I'm  already discussing 
your proposition)?


Jacques


shared library structure we are discussing.

Does that clarify my points?

Ron



On 12/06/2015 9:51 AM, Nicolas Malin wrote:

Ron I didn't understand why you want adding specialization directory directly 
on main component (like entitydef/general/UK/).

For me this information need to be set on the dedicate component in hot-deploy.

Nicolas

Le 12/06/2015 13:17, Ron Wheeler a écrit :

It would be nice to get the philosophy of the structure agreed at the beginning 
even if there is only one variant of accounting-entitymodel.xml .
It might prevent conflicts over the content of some of the files and encourage more contributors who are confident about how their definitions 
work but are unwilling to change someone else's working set of entities, to contribute their variants.


For example, I could  supply my idea of what the Canadian 
accounting-entitymodel.xml should contain without breaking something that 
others are using.

An alternative scheme that might be easier to use would be to structure the 
files as
entitydef/accounting-entitymodel.xml
entitydef/ecommerce-entitymodel.xml
entitydef/general/UK/accounting-entitymodel.xml
entitydef/general/UK/ecommerce-entitymodel.xml

I am not sure that adding applications/datamodel to the front adds any value
entitydef is pretty unambiguous.

Putting the variants first would mean that all of the default entity 
definitions are in one folder and general/UK would all be in another.
To get a complete set, copy everything from entitydef and then copy everything from entitydef/general/UK to get the overrides required t create 
the UK variant.


Ron

On 12/06/2015 2:39 AM, Jacques Le Roux wrote:

Le 11/06/2015 21:10, Ron Wheeler a écrit :
I would suggest adding other levels to the structure so that specializations are easy to add without creating conflicts or constant flux as 
people alter the accounting-entitymodel.xml to suit their needs and submit it as the "right" version".


applications/datamodel/entitidef/accounting-entitymodel.xml
might be better structured as
applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/general/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml
applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml
applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml

It may be that the first specialization will be by country or region to get the 
vocabulary or regulatory compliance particularities separated

applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA_MX/accounting-entit

Re: Move Application Entity Definitions to A Separate Component

2015-06-13 Thread Pierre Smits 
Are we still talking about entity definitions?

I would like to see where the universal data model misses elements
regarding any locale.

Best regards,

Pierre

On Saturday, June 13, 2015, Ron Wheeler 
wrote:

> a) I am not sure why applications/datamodel/entitidef/ could not be
> entitydef/ since it is shorter and unambiguous and spells entity correctly.
> b) I thought that hot-deploy was for local customizations. "entitydef/..."
> are user contributed libraries that are part of the standard OFBiz project
> to support industry-specific or locale-specific requirements.
> c) I am suggesting a structure that makes it easy for someone customizing
> their implementation. Take all the xml files under entitydef ( or
> entitydef/default or entity/basic) and overwrite them with the set of XML
> files suitable for the particular locale that you want such as
> entitydef/eCommerce/NAFTA to get the definitions that match an eCommerce
> site in North America US and Canada terminology and the extensions or
> modifications required to support an eCommerce-only OFBiz aimed at a North
> American clientele.
> If the system integrator does further customization and wants to put their
> branding or  customer-specific overrides in hot-deploy at run-time to keep
> them separate from the XML files that come from OFBiz, that sounds like a
> good practice but is different from the shared library structure we are
> discussing.
>
> Does that clarify my points?
>
> Ron
>
>
>
> On 12/06/2015 9:51 AM, Nicolas Malin wrote:
>
>> Ron I didn't understand why you want adding specialization directory
>> directly on main component (like entitydef/general/UK/).
>>
>> For me this information need to be set on the dedicate component in
>> hot-deploy.
>>
>> Nicolas
>>
>> Le 12/06/2015 13:17, Ron Wheeler a écrit :
>>
>>> It would be nice to get the philosophy of the structure agreed at the
>>> beginning even if there is only one variant of accounting-entitymodel.xml .
>>> It might prevent conflicts over the content of some of the files and
>>> encourage more contributors who are confident about how their definitions
>>> work but are unwilling to change someone else's working set of entities, to
>>> contribute their variants.
>>>
>>> For example, I could  supply my idea of what the Canadian
>>> accounting-entitymodel.xml should contain without breaking something that
>>> others are using.
>>>
>>> An alternative scheme that might be easier to use would be to structure
>>> the files as
>>> entitydef/accounting-entitymodel.xml
>>> entitydef/ecommerce-entitymodel.xml
>>> entitydef/general/UK/accounting-entitymodel.xml
>>> entitydef/general/UK/ecommerce-entitymodel.xml
>>>
>>> I am not sure that adding applications/datamodel to the front adds any
>>> value
>>> entitydef is pretty unambiguous.
>>>
>>> Putting the variants first would mean that all of the default entity
>>> definitions are in one folder and general/UK would all be in another.
>>> To get a complete set, copy everything from entitydef and then copy
>>> everything from entitydef/general/UK to get the overrides required t create
>>> the UK variant.
>>>
>>> Ron
>>>
>>> On 12/06/2015 2:39 AM, Jacques Le Roux wrote:
>>>
 Le 11/06/2015 21:10, Ron Wheeler a écrit :

> I would suggest adding other levels to the structure so that
> specializations are easy to add without creating conflicts or constant 
> flux
> as people alter the accounting-entitymodel.xml to suit their needs and
> submit it as the "right" version".
>
> applications/datamodel/entitidef/accounting-entitymodel.xml
> might be better structured as
> applications/datamodel/entitidef/demo/accounting-entitymodel.xml
> applications/datamodel/entitidef/general/accounting-entitymodel.xml
> applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml
>
> applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml
>
> applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml
>
> It may be that the first specialization will be by country or region
> to get the vocabulary or regulatory compliance particularities separated
>
> applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
> applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml
>
> applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml
>
> applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml
>
> applications/datamodel/entitidef/demo/accounting-entitymodel.xml
> applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
> applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml
> applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml
>
> applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml
>
> applications/datamodel/entitidef/eCommerce/EU/accounting-enti

Re: Move Application Entity Definitions to A Separate Component

2015-06-13 Thread Ron Wheeler 
a) I am not sure why applications/datamodel/entitidef/ could not be 
entitydef/ since it is shorter and unambiguous and spells entity correctly.
b) I thought that hot-deploy was for local customizations. 
"entitydef/..." are user contributed libraries that are part of the 
standard OFBiz project to support industry-specific or locale-specific 
requirements.
c) I am suggesting a structure that makes it easy for someone 
customizing their implementation. Take all the xml files under entitydef 
( or entitydef/default or entity/basic) and overwrite them with the set 
of XML files suitable for the particular locale that you want such as 
entitydef/eCommerce/NAFTA to get the definitions that match an eCommerce 
site in North America US and Canada terminology and the extensions or 
modifications required to support an eCommerce-only OFBiz aimed at a 
North American clientele.
If the system integrator does further customization and wants to put 
their branding or  customer-specific overrides in hot-deploy at run-time 
to keep them separate from the XML files that come from OFBiz, that 
sounds like a good practice but is different from the shared library 
structure we are discussing.


Does that clarify my points?

Ron



On 12/06/2015 9:51 AM, Nicolas Malin wrote:
Ron I didn't understand why you want adding specialization directory 
directly on main component (like entitydef/general/UK/).


For me this information need to be set on the dedicate component in 
hot-deploy.


Nicolas

Le 12/06/2015 13:17, Ron Wheeler a écrit :
It would be nice to get the philosophy of the structure agreed at the 
beginning even if there is only one variant of 
accounting-entitymodel.xml .
It might prevent conflicts over the content of some of the files and 
encourage more contributors who are confident about how their 
definitions work but are unwilling to change someone else's working 
set of entities, to contribute their variants.


For example, I could  supply my idea of what the Canadian 
accounting-entitymodel.xml should contain without breaking something 
that others are using.


An alternative scheme that might be easier to use would be to 
structure the files as

entitydef/accounting-entitymodel.xml
entitydef/ecommerce-entitymodel.xml
entitydef/general/UK/accounting-entitymodel.xml
entitydef/general/UK/ecommerce-entitymodel.xml

I am not sure that adding applications/datamodel to the front adds 
any value

entitydef is pretty unambiguous.

Putting the variants first would mean that all of the default entity 
definitions are in one folder and general/UK would all be in another.
To get a complete set, copy everything from entitydef and then copy 
everything from entitydef/general/UK to get the overrides required t 
create the UK variant.


Ron

On 12/06/2015 2:39 AM, Jacques Le Roux wrote:

Le 11/06/2015 21:10, Ron Wheeler a écrit :
I would suggest adding other levels to the structure so that 
specializations are easy to add without creating conflicts or 
constant flux as people alter the accounting-entitymodel.xml to 
suit their needs and submit it as the "right" version".


applications/datamodel/entitidef/accounting-entitymodel.xml
might be better structured as
applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/general/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml 

applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml 


applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml

It may be that the first specialization will be by country or 
region to get the vocabulary or regulatory compliance 
particularities separated


applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml 

applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml 


applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml

applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml 

applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml 

applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml 



Clearly we would start out with only the demo set but I think that 
we could quickly get some of the other alternatives in place as 
people contribute versions that they want to be part of the basic set.


Would it make sense to break accounting-entitymodel.xml into 
separate files for mandatory and optional entities to make it clear 
the entities that can be modified or dropped without affecting OOB 
functionality?


I'm not against the idea, though it needs to be discussed more
Anyway it can be done later as we will go with baby steps a

Re: Move Application Entity Definitions to A Separate Component

2015-06-12 Thread Nicolas Malin 
Ron I didn't understand why you want adding specialization directory 
directly on main component (like entitydef/general/UK/).


For me this information need to be set on the dedicate component in 
hot-deploy.


Nicolas

Le 12/06/2015 13:17, Ron Wheeler a écrit :
It would be nice to get the philosophy of the structure agreed at the 
beginning even if there is only one variant of 
accounting-entitymodel.xml .
It might prevent conflicts over the content of some of the files and 
encourage more contributors who are confident about how their 
definitions work but are unwilling to change someone else's working 
set of entities, to contribute their variants.


For example, I could  supply my idea of what the Canadian 
accounting-entitymodel.xml should contain without breaking something 
that others are using.


An alternative scheme that might be easier to use would be to 
structure the files as

entitydef/accounting-entitymodel.xml
entitydef/ecommerce-entitymodel.xml
entitydef/general/UK/accounting-entitymodel.xml
entitydef/general/UK/ecommerce-entitymodel.xml

I am not sure that adding applications/datamodel to the front adds any 
value

entitydef is pretty unambiguous.

Putting the variants first would mean that all of the default entity 
definitions are in one folder and general/UK would all be in another.
To get a complete set, copy everything from entitydef and then copy 
everything from entitydef/general/UK to get the overrides required t 
create the UK variant.


Ron

On 12/06/2015 2:39 AM, Jacques Le Roux wrote:

Le 11/06/2015 21:10, Ron Wheeler a écrit :
I would suggest adding other levels  to the structure so that 
specializations are easy to add without creating conflicts or 
constant flux as people alter the accounting-entitymodel.xml to suit 
their needs and submit it as the "right" version".


applications/datamodel/entitidef/accounting-entitymodel.xml
might be better structured as
applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/general/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml 

applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml 


applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml

It may be that the first specialization will be by country or region 
to get the vocabulary or regulatory compliance particularities 
separated


applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml 

applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml 


applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml

applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml 

applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml 

applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml 



Clearly we would start out with only the demo set but I think that 
we could quickly get some of the other alternatives in place as 
people contribute versions that they want to be part of the basic set.


Would it make sense to break accounting-entitymodel.xml into 
separate files for mandatory and optional entities to make it clear 
the entities that can be modified or dropped without affecting OOB 
functionality?


I'm not against the idea, though it needs to be discussed more
Anyway it can be done later as we will go with baby steps as Jacopo 
suggested


Jacques



Ron


On 11/06/2015 10:18 AM, Jacopo Cappellato wrote:
On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb 
 wrote:


I would like to help and I think we need to think carefully of the 
layout / structure though i.e. how to breakup the entities in 
files and/or directories.
I would suggest that, at least in the first step, we do it in a 
simple way like the following:


1) create the new component, named for example "datamodel" (please 
suggest a better name)
2) move all the entity xml files from the applications to the 
"datamodel" component keeping the files separated as they are, but 
adding a prefix; for example


applications/accounting/entitidef/entitymodel.xml

will be moved to:

applications/datamodel/entitidef/accounting-entitymodel.xml

The end result will be a "datamodel" component with an entitidef/ 
folder containing several files, approximately one per application 
component


3) similar approach for eeca files

4) add the relevant entries in

applications/datamodel/ofbiz-component.xml

Regards,

Jacopo

Re: Move Application Entity Definitions to A Separate Component

2015-06-12 Thread Nicolas Malin 

Le 11/06/2015 16:18, Jacopo Cappellato a écrit :

On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb  wrote:


I would like to help and I think we need to think carefully of the layout / 
structure though i.e. how to breakup the entities in files and/or directories.

I would suggest that, at least in the first step, we do it in a simple way like 
the following:

1) create the new component, named for example "datamodel" (please suggest a 
better name)

applications/common-layer
applications/functional-layer

2) move all the entity xml files from the applications to the "datamodel" 
component keeping the files separated as they are, but adding a prefix; for example

applications/accounting/entitidef/entitymodel.xml

will be moved to:

applications/datamodel/entitidef/accounting-entitymodel.xml

The end result will be a "datamodel" component with an entitidef/ folder 
containing several files, approximately one per application component
My preference goes to use the package path but add complexity for few. I 
see :

applications/functional-layer/entitydef/model/entitymodel-accounting.xml
applications/functional-layer/entitydef/eca/eeca-accounting.xml
applications/functional-layer/servicedef/model/services-accounting.xml
applications/functional-layer/servicedef/eca/seca-accounting.xml

But currently some component already have multiple entitymodel file to 
segment entities so why not :


applications/functional-layer/entitydef/model/accounting/entitymodel.xml
applications/functional-layer/entitydef/model/accounting/entitymodel-invoice.xml
applications/functional-layer/entitydef/model/accounting/entitymodel-payment.xml
applications/functional-layer/entitydef/eca/accounting/eeca.xml


3) similar approach for eeca files

4) add the relevant entries in

applications/datamodel/ofbiz-component.xml

We can simplify entries with regexp like this
location="entitydef/model/*"/>

or just
dir-location="entitydef/model/accounting/"/>


Nicolas


Regards,

Jacopo

Re: Move Application Entity Definitions to A Separate Component

2015-06-12 Thread Taher Alkhateeb 
Hi Ron and All, 

I like the structure you suggested below. Short, sweet and to the point. I 
suggest we name them as domains, not as components. So we follow the Data Model 
Resource Book and break the names into things like invoicing, workeffort, 
shipment, order, party, human-resources etc ... and not necessarily into 
component names. 

Taher Alkhateeb 

- Original Message -

From: "Ron Wheeler"  
To: dev@ofbiz.apache.org 
Sent: Friday, 12 June, 2015 2:17:50 PM 
Subject: Re: Move Application Entity Definitions to A Separate Component 

It would be nice to get the philosophy of the structure agreed at the 
beginning even if there is only one variant of accounting-entitymodel.xml . 
It might prevent conflicts over the content of some of the files and 
encourage more contributors who are confident about how their 
definitions work but are unwilling to change someone else's working set 
of entities, to contribute their variants. 

For example, I could supply my idea of what the Canadian 
accounting-entitymodel.xml should contain without breaking something 
that others are using. 

An alternative scheme that might be easier to use would be to structure 
the files as 
entitydef/accounting-entitymodel.xml 
entitydef/ecommerce-entitymodel.xml 
entitydef/general/UK/accounting-entitymodel.xml 
entitydef/general/UK/ecommerce-entitymodel.xml 

I am not sure that adding applications/datamodel to the front adds any value 
entitydef is pretty unambiguous. 

Putting the variants first would mean that all of the default entity 
definitions are in one folder and general/UK would all be in another. 
To get a complete set, copy everything from entitydef and then copy 
everything from entitydef/general/UK to get the overrides required t 
create the UK variant. 

Ron 

On 12/06/2015 2:39 AM, Jacques Le Roux wrote: 
> Le 11/06/2015 21:10, Ron Wheeler a écrit : 
>> I would suggest adding other levels to the structure so that 
>> specializations are easy to add without creating conflicts or 
>> constant flux as people alter the accounting-entitymodel.xml to suit 
>> their needs and submit it as the "right" version". 
>> 
>> applications/datamodel/entitidef/accounting-entitymodel.xml 
>> might be better structured as 
>> applications/datamodel/entitidef/demo/accounting-entitymodel.xml 
>> applications/datamodel/entitidef/general/accounting-entitymodel.xml 
>> applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml 
>> 
>> applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml
>>  
>> 
>> applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml 
>> 
>> It may be that the first specialization will be by country or region 
>> to get the vocabulary or regulatory compliance particularities separated 
>> 
>> applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml 
>> applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml 
>> 
>> applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml 
>> 
>> applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml 
>> 
>> applications/datamodel/entitidef/demo/accounting-entitymodel.xml 
>> applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml 
>> applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml 
>> applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml 
>> 
>> applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml
>>  
>> 
>> applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml 
>> 
>> Clearly we would start out with only the demo set but I think that we 
>> could quickly get some of the other alternatives in place as people 
>> contribute versions that they want to be part of the basic set. 
>> 
>> Would it make sense to break accounting-entitymodel.xml into separate 
>> files for mandatory and optional entities to make it clear the 
>> entities that can be modified or dropped without affecting OOB 
>> functionality? 
> 
> I'm not against the idea, though it needs to be discussed more 
> Anyway it can be done later as we will go with baby steps as Jacopo 
> suggested 
> 
> Jacques 
> 
>> 
>> Ron 
>> 
>> 
>> On 11/06/2015 10:18 AM, Jacopo Cappellato wrote: 
>>> On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb 
>>>  wrote: 
>>> 
>>>> I would like to help and I think we need to think carefully of the 
>>>> layout / structure though i.e. how to breakup the entities in files 
>>>> and/or directories. 
>>> I would suggest that, at least in the f

Re: Move Application Entity Definitions to A Separate Component

2015-06-12 Thread Ron Wheeler 
It would be nice to get the philosophy of the structure agreed at the 
beginning even if there is only one variant of accounting-entitymodel.xml .
It might prevent conflicts over the content of some of the files and 
encourage more contributors who are confident about how their 
definitions work but are unwilling to change someone else's working set 
of entities, to contribute their variants.


For example, I could  supply my idea of what the Canadian 
accounting-entitymodel.xml should contain without breaking something 
that others are using.


An alternative scheme that might be easier to use would be to structure 
the files as

entitydef/accounting-entitymodel.xml
entitydef/ecommerce-entitymodel.xml
entitydef/general/UK/accounting-entitymodel.xml
entitydef/general/UK/ecommerce-entitymodel.xml

I am not sure that adding applications/datamodel to the front adds any value
entitydef is pretty unambiguous.

Putting the variants first would mean that all of the default entity 
definitions are in one folder and general/UK would all be in another.
To get a complete set, copy everything from entitydef and then copy 
everything from entitydef/general/UK to get the overrides required t 
create the UK variant.


Ron

On 12/06/2015 2:39 AM, Jacques Le Roux wrote:

Le 11/06/2015 21:10, Ron Wheeler a écrit :
I would suggest adding other levels  to the structure so that 
specializations are easy to add without creating conflicts or 
constant flux as people alter the accounting-entitymodel.xml to suit 
their needs and submit it as the "right" version".


applications/datamodel/entitidef/accounting-entitymodel.xml
might be better structured as
applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/general/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml 

applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml 


applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml

It may be that the first specialization will be by country or region 
to get the vocabulary or regulatory compliance particularities separated


applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml 

applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml 


applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml

applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml 

applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml 


applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml

Clearly we would start out with only the demo set but I think that we 
could quickly get some of the other alternatives in place as people 
contribute versions that they want to be part of the basic set.


Would it make sense to break accounting-entitymodel.xml into separate 
files for mandatory and optional entities to make it clear the 
entities that can be modified or dropped without affecting OOB 
functionality?


I'm not against the idea, though it needs to be discussed more
Anyway it can be done later as we will go with baby steps as Jacopo 
suggested


Jacques



Ron


On 11/06/2015 10:18 AM, Jacopo Cappellato wrote:
On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb 
 wrote:


I would like to help and I think we need to think carefully of the 
layout / structure though i.e. how to breakup the entities in files 
and/or directories.
I would suggest that, at least in the first step, we do it in a 
simple way like the following:


1) create the new component, named for example "datamodel" (please 
suggest a better name)
2) move all the entity xml files from the applications to the 
"datamodel" component keeping the files separated as they are, but 
adding a prefix; for example


applications/accounting/entitidef/entitymodel.xml

will be moved to:

applications/datamodel/entitidef/accounting-entitymodel.xml

The end result will be a "datamodel" component with an entitidef/ 
folder containing several files, approximately one per application 
component


3) similar approach for eeca files

4) add the relevant entries in

applications/datamodel/ofbiz-component.xml

Regards,

Jacopo











--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Move Application Entity Definitions to A Separate Component

2015-06-12 Thread Ron Wheeler 
I am not sure that restructuring the folder and separating the 
definitions mean that we have to consolidate all accounting entities 
into one file but separating code from data is the core of this idea.


Ron


On 12/06/2015 2:45 AM, Pierre Smits wrote:

I don't agree that moving in this direction will convince our potential
adopters to chose OFBiz. Having all entities in one component doestn't give
them more choice. Neither does having all eecas in one component.

Today it is already possible to have the entity definitions split up into
multiple files to create more clarity as to what each component delivers.
The same can be said for eecas and other services. Maybe we should embark
on that, before we decide to move it all to one monolithical entity
component.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Fri, Jun 12, 2015 at 8:39 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 11/06/2015 21:10, Ron Wheeler a écrit :


I would suggest adding other levels  to the structure so that
specializations are easy to add without creating conflicts or constant flux
as people alter the accounting-entitymodel.xml to suit their needs and
submit it as the "right" version".

applications/datamodel/entitidef/accounting-entitymodel.xml
might be better structured as
applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/general/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml

applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml
applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml

It may be that the first specialization will be by country or region to
get the vocabulary or regulatory compliance particularities separated

applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml

applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml
applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml

applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml

applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml

applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml
applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml

Clearly we would start out with only the demo set but I think that we
could quickly get some of the other alternatives in place as people
contribute versions that they want to be part of the basic set.

Would it make sense to break accounting-entitymodel.xml into separate
files for mandatory and optional entities to make it clear the entities
that can be modified or dropped without affecting OOB functionality?


I'm not against the idea, though it needs to be discussed more
Anyway it can be done later as we will go with baby steps as Jacopo
suggested

Jacques




Ron


On 11/06/2015 10:18 AM, Jacopo Cappellato wrote:


On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb 
wrote:

  I would like to help and I think we need to think carefully of the

layout / structure though i.e. how to breakup the entities in files and/or
directories.


I would suggest that, at least in the first step, we do it in a simple
way like the following:

1) create the new component, named for example "datamodel" (please
suggest a better name)
2) move all the entity xml files from the applications to the
"datamodel" component keeping the files separated as they are, but adding a
prefix; for example

applications/accounting/entitidef/entitymodel.xml

will be moved to:

applications/datamodel/entitidef/accounting-entitymodel.xml

The end result will be a "datamodel" component with an entitidef/ folder
containing several files, approximately one per application component

3) similar approach for eeca files

4) add the relevant entries in

applications/datamodel/ofbiz-component.xml

Regards,

Jacopo









--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Move Application Entity Definitions to A Separate Component

2015-06-11 Thread Jacopo Cappellato 

On Jun 12, 2015, at 8:45 AM, Pierre Smits  wrote:

> I don't agree that moving in this direction will convince our potential
> adopters to chose OFBiz. Having all entities in one component doestn't give
> them more choice. Neither does having all eecas in one component.
> 
> Today it is already possible to have the entity definitions split up into
> multiple files to create more clarity as to what each component delivers.
> The same can be said for eecas and other services. Maybe we should embark
> on that, before we decide to move it all to one monolithical entity
> component.

The files will be split into business domain areas, not different from now; the 
advantage is that the new component will make it easy to deploy a data model 
only system (framework + data model) for the ones interested in building custom 
applications on top of it.
Currently you cannot deploy a subset of the data model (e.g. accounting) 
because the foreign key relationship between entities: the layout changes we 
are discussing will not make this worse or better... you could still remove an 
entity definition line in ofbiz-component.xml to disable some entities.

Regards,

Jacopo

> 
> Best regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> On Fri, Jun 12, 2015 at 8:39 AM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
> 
>> Le 11/06/2015 21:10, Ron Wheeler a écrit :
>> 
>>> I would suggest adding other levels  to the structure so that
>>> specializations are easy to add without creating conflicts or constant flux
>>> as people alter the accounting-entitymodel.xml to suit their needs and
>>> submit it as the "right" version".
>>> 
>>> applications/datamodel/entitidef/accounting-entitymodel.xml
>>> might be better structured as
>>> applications/datamodel/entitidef/demo/accounting-entitymodel.xml
>>> applications/datamodel/entitidef/general/accounting-entitymodel.xml
>>> applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml
>>> 
>>> applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml
>>> applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml
>>> 
>>> It may be that the first specialization will be by country or region to
>>> get the vocabulary or regulatory compliance particularities separated
>>> 
>>> applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
>>> applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml
>>> 
>>> applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml
>>> applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml
>>> 
>>> applications/datamodel/entitidef/demo/accounting-entitymodel.xml
>>> applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
>>> applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml
>>> 
>>> applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml
>>> 
>>> applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml
>>> applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml
>>> 
>>> Clearly we would start out with only the demo set but I think that we
>>> could quickly get some of the other alternatives in place as people
>>> contribute versions that they want to be part of the basic set.
>>> 
>>> Would it make sense to break accounting-entitymodel.xml into separate
>>> files for mandatory and optional entities to make it clear the entities
>>> that can be modified or dropped without affecting OOB functionality?
>>> 
>> 
>> I'm not against the idea, though it needs to be discussed more
>> Anyway it can be done later as we will go with baby steps as Jacopo
>> suggested
>> 
>> Jacques
>> 
>> 
>> 
>>> Ron
>>> 
>>> 
>>> On 11/06/2015 10:18 AM, Jacopo Cappellato wrote:
>>> 
 On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb 
 wrote:
 
 I would like to help and I think we need to think carefully of the
> layout / structure though i.e. how to breakup the entities in files and/or
> directories.
> 
 I would suggest that, at least in the first step, we do it in a simple
 way like the following:
 
 1) create the new component, named for example "datamodel" (please
 suggest a better name)
 2) move all the entity xml files from the applications to the
 "datamodel" component keeping the files separated as they are, but adding a
 prefix; for example
 
 applications/accounting/entitidef/entitymodel.xml
 
 will be moved to:
 
 applications/datamodel/entitidef/accounting-entitymodel.xml
 
 The end result will be a "datamodel" component with an entitidef/ folder
 containing several files, approximately one per application component
 
 3) similar approach for eeca files
 
 4) add the relevant entries in
 
 applications/d

Re: Move Application Entity Definitions to A Separate Component

2015-06-11 Thread Pierre Smits 
I don't agree that moving in this direction will convince our potential
adopters to chose OFBiz. Having all entities in one component doestn't give
them more choice. Neither does having all eecas in one component.

Today it is already possible to have the entity definitions split up into
multiple files to create more clarity as to what each component delivers.
The same can be said for eecas and other services. Maybe we should embark
on that, before we decide to move it all to one monolithical entity
component.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Fri, Jun 12, 2015 at 8:39 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 11/06/2015 21:10, Ron Wheeler a écrit :
>
>> I would suggest adding other levels  to the structure so that
>> specializations are easy to add without creating conflicts or constant flux
>> as people alter the accounting-entitymodel.xml to suit their needs and
>> submit it as the "right" version".
>>
>> applications/datamodel/entitidef/accounting-entitymodel.xml
>> might be better structured as
>> applications/datamodel/entitidef/demo/accounting-entitymodel.xml
>> applications/datamodel/entitidef/general/accounting-entitymodel.xml
>> applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml
>>
>> applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml
>> applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml
>>
>> It may be that the first specialization will be by country or region to
>> get the vocabulary or regulatory compliance particularities separated
>>
>> applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
>> applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml
>>
>> applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml
>> applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml
>>
>> applications/datamodel/entitidef/demo/accounting-entitymodel.xml
>> applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
>> applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml
>>
>> applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml
>>
>> applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml
>> applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml
>>
>> Clearly we would start out with only the demo set but I think that we
>> could quickly get some of the other alternatives in place as people
>> contribute versions that they want to be part of the basic set.
>>
>> Would it make sense to break accounting-entitymodel.xml into separate
>> files for mandatory and optional entities to make it clear the entities
>> that can be modified or dropped without affecting OOB functionality?
>>
>
> I'm not against the idea, though it needs to be discussed more
> Anyway it can be done later as we will go with baby steps as Jacopo
> suggested
>
> Jacques
>
>
>
>> Ron
>>
>>
>> On 11/06/2015 10:18 AM, Jacopo Cappellato wrote:
>>
>>> On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb 
>>> wrote:
>>>
>>>  I would like to help and I think we need to think carefully of the
 layout / structure though i.e. how to breakup the entities in files and/or
 directories.

>>> I would suggest that, at least in the first step, we do it in a simple
>>> way like the following:
>>>
>>> 1) create the new component, named for example "datamodel" (please
>>> suggest a better name)
>>> 2) move all the entity xml files from the applications to the
>>> "datamodel" component keeping the files separated as they are, but adding a
>>> prefix; for example
>>>
>>> applications/accounting/entitidef/entitymodel.xml
>>>
>>> will be moved to:
>>>
>>> applications/datamodel/entitidef/accounting-entitymodel.xml
>>>
>>> The end result will be a "datamodel" component with an entitidef/ folder
>>> containing several files, approximately one per application component
>>>
>>> 3) similar approach for eeca files
>>>
>>> 4) add the relevant entries in
>>>
>>> applications/datamodel/ofbiz-component.xml
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>>
>>>
>>>
>>
>>

Re: Move Application Entity Definitions to A Separate Component

2015-06-11 Thread Jacques Le Roux 

Le 11/06/2015 21:10, Ron Wheeler a écrit :
I would suggest adding other levels  to the structure so that specializations are easy to add without creating conflicts or constant flux as people 
alter the accounting-entitymodel.xml to suit their needs and submit it as the "right" version".


applications/datamodel/entitidef/accounting-entitymodel.xml
might be better structured as
applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/general/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml
applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml
applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml

It may be that the first specialization will be by country or region to get the 
vocabulary or regulatory compliance particularities separated

applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml
applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml

applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml
applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml

Clearly we would start out with only the demo set but I think that we could quickly get some of the other alternatives in place as people contribute 
versions that they want to be part of the basic set.


Would it make sense to break accounting-entitymodel.xml into separate files for mandatory and optional entities to make it clear the entities that 
can be modified or dropped without affecting OOB functionality?


I'm not against the idea, though it needs to be discussed more
Anyway it can be done later as we will go with baby steps as Jacopo suggested

Jacques



Ron


On 11/06/2015 10:18 AM, Jacopo Cappellato wrote:

On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb  wrote:

I would like to help and I think we need to think carefully of the layout / structure though i.e. how to breakup the entities in files and/or 
directories.

I would suggest that, at least in the first step, we do it in a simple way like 
the following:

1) create the new component, named for example "datamodel" (please suggest a 
better name)
2) move all the entity xml files from the applications to the "datamodel" component keeping the files separated as they are, but adding a prefix; 
for example


applications/accounting/entitidef/entitymodel.xml

will be moved to:

applications/datamodel/entitidef/accounting-entitymodel.xml

The end result will be a "datamodel" component with an entitidef/ folder 
containing several files, approximately one per application component

3) similar approach for eeca files

4) add the relevant entries in

applications/datamodel/ofbiz-component.xml

Regards,

Jacopo

Re: Move Application Entity Definitions to A Separate Component

2015-06-11 Thread Jacques Le Roux 

Le 11/06/2015 16:18, Jacopo Cappellato a écrit :

On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb  wrote:


I would like to help and I think we need to think carefully of the layout / 
structure though i.e. how to breakup the entities in files and/or directories.

I would suggest that, at least in the first step, we do it in a simple way like 
the following:

1) create the new component, named for example "datamodel" (please suggest a 
better name)
2) move all the entity xml files from the applications to the "datamodel" 
component keeping the files separated as they are, but adding a prefix; for example

applications/accounting/entitidef/entitymodel.xml

will be moved to:

applications/datamodel/entitidef/accounting-entitymodel.xml


This will indeed make the files more easy to find (though I generally look for 
entities not files)



The end result will be a "datamodel" component with an entitidef/ folder 
containing several files, approximately one per application component

3) similar approach for eeca files

I like the idea of having the eeca files more visible

BTW, for those interest this discussion began here 
https://cwiki.apache.org/confluence/display/OFBIZ/Roadmap+Diagrams+-+In+Progress

Jacques


4) add the relevant entries in

applications/datamodel/ofbiz-component.xml

Regards,

Jacopo

Re: Move Application Entity Definitions to A Separate Component

2015-06-11 Thread Ron Wheeler 
I would suggest adding other levels  to the structure so that 
specializations are easy to add without creating conflicts or constant 
flux as people alter the accounting-entitymodel.xml to suit their needs 
and submit it as the "right" version".


applications/datamodel/entitidef/accounting-entitymodel.xml
might be better structured as
applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/general/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml
applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml
applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml

It may be that the first specialization will be by country or region to get the 
vocabulary or regulatory compliance particularities separated

applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml
applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml

applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml
applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml

Clearly we would start out with only the demo set but I think that we could 
quickly get some of the other alternatives in place as people contribute 
versions that they want to be part of the basic set.

Would it make sense to break accounting-entitymodel.xml into separate files for 
mandatory and optional entities to make it clear the entities that can be 
modified or dropped without affecting OOB functionality?

Ron


On 11/06/2015 10:18 AM, Jacopo Cappellato wrote:

On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb  wrote:


I would like to help and I think we need to think carefully of the layout / 
structure though i.e. how to breakup the entities in files and/or directories.

I would suggest that, at least in the first step, we do it in a simple way like 
the following:

1) create the new component, named for example "datamodel" (please suggest a 
better name)
2) move all the entity xml files from the applications to the "datamodel" 
component keeping the files separated as they are, but adding a prefix; for example

applications/accounting/entitidef/entitymodel.xml

will be moved to:

applications/datamodel/entitidef/accounting-entitymodel.xml

The end result will be a "datamodel" component with an entitidef/ folder 
containing several files, approximately one per application component

3) similar approach for eeca files

4) add the relevant entries in

applications/datamodel/ofbiz-component.xml

Regards,

Jacopo






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Move Application Entity Definitions to A Separate Component

2015-06-11 Thread Jacopo Cappellato 
On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb  wrote:

> I would like to help and I think we need to think carefully of the layout / 
> structure though i.e. how to breakup the entities in files and/or directories.

I would suggest that, at least in the first step, we do it in a simple way like 
the following:

1) create the new component, named for example "datamodel" (please suggest a 
better name)
2) move all the entity xml files from the applications to the "datamodel" 
component keeping the files separated as they are, but adding a prefix; for 
example

applications/accounting/entitidef/entitymodel.xml

will be moved to:

applications/datamodel/entitidef/accounting-entitymodel.xml

The end result will be a "datamodel" component with an entitidef/ folder 
containing several files, approximately one per application component

3) similar approach for eeca files

4) add the relevant entries in 

applications/datamodel/ofbiz-component.xml

Regards,

Jacopo

Re: Move Application Entity Definitions to A Separate Component

2015-06-11 Thread Taher Alkhateeb 
Hi Sharan, 

+1 
I would like to help and I think we need to think carefully of the layout / 
structure though i.e. how to breakup the entities in files and/or directories. 
I think too much structure is painful to maintain and too little is 
overwhelming to navigate through. Perhaps we can categorize in a similar 
fashion to the data model resource book ToC. 

Overall this would be a good first step to reduce component dependency 

Taher Alkhateeb 

- Original Message -

From: "Ron Wheeler"  
To: dev@ofbiz.apache.org 
Sent: Thursday, 11 June, 2015 3:37:51 PM 
Subject: Re: Move Application Entity Definitions to A Separate Component 

+1 
Would like to see the definitions organized in a way that makes it easy 
to see what entities are mandatory "as is" as opposed to customizable. 

Might also want to consider having multiple variations of the entities 
to support different industries, different management focuses or languages. 

These could be contributed by users and maintained by users rather than 
developers. 

Ron 


On 11/06/2015 3:46 AM, Sharan-F wrote: 
> Hi All 
> 
> I'd like to get some feedback on the a proposal Jacopo made a while ago to 
> find out if we have enough consenus to include it in our upcoming Community 
> Day. 
> 
> */Some time ago I proposed to move all entity definitions from the 
> applications components into a separate one; this component could also 
> contain crud/generic services: in this way it will be easier to deploy the 
> framework+data-model without the user interfaces that are not as generic and 
> universal as the data model is. In my opinion this would be a good step in 
> the right direction and it would be very easy to implement. /* 
> 
> So my questions to you all are : 
> 
> 1. Can we reach a consenus as to whether or not we want to do it? 
> 2. And if so, whether we want to include it as part of the work for our 
> Community Day next week? 
> 
> Thanks 
> Sharan 
> 
> 
> 
> -- 
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/Move-Application-Entity-Definitions-to-A-Separate-Component-tp4669903.html
>  
> Sent from the OFBiz - Dev mailing list archive at Nabble.com. 
> 


-- 
Ron Wheeler 
President 
Artifact Software Inc 
email: rwhee...@artifact-software.com 
skype: ronaldmwheeler 
phone: 866-970-2435, ext 102

Re: Move Application Entity Definitions to A Separate Component

2015-06-11 Thread Ron Wheeler 

+1
Would like to see the definitions organized in a way that makes it easy 
to see what entities are mandatory "as is" as opposed to customizable.


Might also want to consider having multiple variations of the entities 
to support different industries, different management focuses or languages.


These could be contributed by users and maintained by users rather than 
developers.


Ron


On 11/06/2015 3:46 AM, Sharan-F wrote:

Hi All

I'd like to get some feedback on the a proposal Jacopo made a while ago to
find out if we have enough consenus to include it in our upcoming Community
Day.

*/Some time ago I proposed to move all entity definitions from the
applications components into a separate one; this component could also
contain crud/generic services: in this way it will be easier to deploy the
framework+data-model without the user interfaces that are not as generic and
universal as the data model is. In my opinion this would be a good step in
the right direction and it would be very easy to implement. /*

So my questions to you all are :

 1. Can we reach a consenus as to whether or not we want to do it?
 2. And if so, whether we want to include it as part of the work for our
Community Day next week?

Thanks
Sharan



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Move-Application-Entity-Definitions-to-A-Separate-Component-tp4669903.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102