[DISCUSSION] Disentanglement of the ExampleExt component

[Pierre Smits-3]

Hi all,

The ExampleExt components provides functionality to extend widgets across
components. In this solution, the ExampleExt component has form widgets
extending similar widgets in the Example component.

This kind of functionality (both within one component and across, and with
more variants) already/also exists in other components in the
ofbiz-framework code base.

So, do we still want to entertain/maintain a component that adds little to
no unique value for our (potential) adopters, even though it is in the
ofbiz-plugin code base?

For what it is worth: the ExampleExt widgets can easily be integrated in
the Example component, and the existence of extended/extending widgets in
the ofbiz-framework code base also serves as examples of what can be
achieved by adopters/contributors.

What are your thoughts?


Best regards,

Pierre Smits

V.P. Apache Trafodion
PMC Member Apache Directory

[taher]

I think all -ext components (entityext, commonext, exampleext) are
redundant and do not add value. Any patches to fix this issue and
merge these components would be great.



On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <[hidden email]> wrote:

> Hi all,
>
> The ExampleExt components provides functionality to extend widgets across
> components. In this solution, the ExampleExt component has form widgets
> extending similar widgets in the Example component.
>
> This kind of functionality (both within one component and across, and with
> more variants) already/also exists in other components in the
> ofbiz-framework code base.
>
> So, do we still want to entertain/maintain a component that adds little to
> no unique value for our (potential) adopters, even though it is in the
> ofbiz-plugin code base?
>
> For what it is worth: the ExampleExt widgets can easily be integrated in
> the Example component, and the existence of extended/extending widgets in
> the ofbiz-framework code base also serves as examples of what can be
> achieved by adopters/contributors.
>
> What are your thoughts?
>
>
> Best regards,
>
> Pierre Smits
>
> V.P. Apache Trafodion
> PMC Member Apache Directory

[Scott Gray-3]

I'm not familiar with commonext or exampleext, but the purpose of the
entity-ext component was to allow the entity engine to exist without the
service engine.  That's why all the entity-related logic that relies on the
service engine is implemented there (EECAs, EntitySync, DCC).  The
alternative would be to have that stuff in the service engine, it can't
exist in the entity engine because you'd have a circular compile-time
dependency.

It effectively exists as a "disentanglement" of the entity and service
engines.

Regards
Scott


On 8 January 2018 at 09:18, Taher Alkhateeb <[hidden email]>
wrote:

> I think all -ext components (entityext, commonext, exampleext) are
> redundant and do not add value. Any patches to fix this issue and
> merge these components would be great.
>
>
>
> On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <[hidden email]>
> wrote:
> > Hi all,
> >
> > The ExampleExt components provides functionality to extend widgets across
> > components. In this solution, the ExampleExt component has form widgets
> > extending similar widgets in the Example component.
> >
> > This kind of functionality (both within one component and across, and
> with
> > more variants) already/also exists in other components in the
> > ofbiz-framework code base.
> >
> > So, do we still want to entertain/maintain a component that adds little
> to
> > no unique value for our (potential) adopters, even though it is in the
> > ofbiz-plugin code base?
> >
> > For what it is worth: the ExampleExt widgets can easily be integrated in
> > the Example component, and the existence of extended/extending widgets in
> > the ofbiz-framework code base also serves as examples of what can be
> > achieved by adopters/contributors.
> >
> > What are your thoughts?
> >
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > V.P. Apache Trafodion
> > PMC Member Apache Directory
>

[Jacques Le Roux]

I'm not against strictly against removing exampleext (maybe merging some part in example ). But then what it not clearly tries to explain (misc.
extension mechanisms) should be clearly documented!

For commonext I need to look at it again but at 1st glance it seems redundant indeed and could be merged with common now that we deliver applications
with framework.

There is also securityext, I did not say we need to merge it, just noticing.

Anyway before doing anything we need to clarify, if possible, why those components were created and what impact it could have (if merged with there
main component) when/if-one-day we split applications and framework.

And if we merge these stuff these pages must get out  also:

https://cwiki.apache.org/confluence/display/OFBENDUSER/Extending+the+common+component

https://cwiki.apache.org/confluence/display/OFBENDUSER/Extending+the+security+component

Jacques


Le 07/01/2018 à 21:55, Scott Gray a écrit :

> I'm not familiar with commonext or exampleext, but the purpose of the
> entity-ext component was to allow the entity engine to exist without the
> service engine.  That's why all the entity-related logic that relies on the
> service engine is implemented there (EECAs, EntitySync, DCC).  The
> alternative would be to have that stuff in the service engine, it can't
> exist in the entity engine because you'd have a circular compile-time
> dependency.
>
> It effectively exists as a "disentanglement" of the entity and service
> engines.
>
> Regards
> Scott
>
>
> On 8 January 2018 at 09:18, Taher Alkhateeb <[hidden email]>
> wrote:
>
>> I think all -ext components (entityext, commonext, exampleext) are
>> redundant and do not add value. Any patches to fix this issue and
>> merge these components would be great.
>>
>>
>>
>> On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <[hidden email]>
>> wrote:
>>> Hi all,
>>>
>>> The ExampleExt components provides functionality to extend widgets across
>>> components. In this solution, the ExampleExt component has form widgets
>>> extending similar widgets in the Example component.
>>>
>>> This kind of functionality (both within one component and across, and
>> with
>>> more variants) already/also exists in other components in the
>>> ofbiz-framework code base.
>>>
>>> So, do we still want to entertain/maintain a component that adds little
>> to
>>> no unique value for our (potential) adopters, even though it is in the
>>> ofbiz-plugin code base?
>>>
>>> For what it is worth: the ExampleExt widgets can easily be integrated in
>>> the Example component, and the existence of extended/extending widgets in
>>> the ofbiz-framework code base also serves as examples of what can be
>>> achieved by adopters/contributors.
>>>
>>> What are your thoughts?
>>>
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> V.P. Apache Trafodion
>>> PMC Member Apache Directory

[Jacopo Cappellato-5]

Scott is making a good point about entity-ext: in my opinion the design is
good (but can be improved).
I suspect that commonext and exampleext have a less clean implementation
and maybe they do not even implement that pattern, I see less value in them.

One comment on entity-ext: In my opinion we should (for this and for
several other parts of the framework) continue the work to make the
framework code more modular (with core independent modules and with
extended modules that depend on them etc...) but I don't think that the
building block should be the "OFBiz component" as it is now. It would be
better to rely on jar files instead.
For example:
entity-core-api.jar
  entity-core-impl.jar
service-core-api.jar
  service-core-impl.jar

service-entity.jar that provides the integration of services with the
entity engine and depends on entity-core-api.jar and service-core-api.jar

We could define several granular modules that would allow to deploy
different flavors of the framework, e.g.:
1) entity-core-api.jar + entity-core-impl.jar: entity engine available to
legacy applications (built from scratch)
2) service-core-api.jar + service-core-impl.jar: service engine available
to legacy applications (built from scratch)
3) entity-core-api.jar + entity-core-custom impl.jar: custom entity engine
available to legacy applications (built from scratch)
etc...

Jacopo

On Sun, Jan 7, 2018 at 9:55 PM, Scott Gray <[hidden email]>
wrote:

> I'm not familiar with commonext or exampleext, but the purpose of the
> entity-ext component was to allow the entity engine to exist without the
> service engine.  That's why all the entity-related logic that relies on the
> service engine is implemented there (EECAs, EntitySync, DCC).  The
> alternative would be to have that stuff in the service engine, it can't
> exist in the entity engine because you'd have a circular compile-time
> dependency.
>
> It effectively exists as a "disentanglement" of the entity and service
> engines.
>
> Regards
> Scott
>
>
> On 8 January 2018 at 09:18, Taher Alkhateeb <[hidden email]>
> wrote:
>
> > I think all -ext components (entityext, commonext, exampleext) are
> > redundant and do not add value. Any patches to fix this issue and
> > merge these components would be great.
> >
> >
> >
> > On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <[hidden email]>
> > wrote:
> > > Hi all,
> > >
> > > The ExampleExt components provides functionality to extend widgets
> across
> > > components. In this solution, the ExampleExt component has form widgets
> > > extending similar widgets in the Example component.
> > >
> > > This kind of functionality (both within one component and across, and
> > with
> > > more variants) already/also exists in other components in the
> > > ofbiz-framework code base.
> > >
> > > So, do we still want to entertain/maintain a component that adds little
> > to
> > > no unique value for our (potential) adopters, even though it is in the
> > > ofbiz-plugin code base?
> > >
> > > For what it is worth: the ExampleExt widgets can easily be integrated
> in
> > > the Example component, and the existence of extended/extending widgets
> in
> > > the ofbiz-framework code base also serves as examples of what can be
> > > achieved by adopters/contributors.
> > >
> > > What are your thoughts?
> > >
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > V.P. Apache Trafodion
> > > PMC Member Apache Directory
> >
>

[taher]

I stand corrected, Scott made a very good point regarding entityext
that I did not pay enough attention to. Perhaps the name is misleading
though, entityext means an enhancement or extension of the
capabilities of the entity component which does not make a lot of
sense. If it was called entity-service or entity-service-map or
something like might have been more direct and self explanatory.

I think Jacopo's comment of moving away from components to jars as the
building blocks (at least for the framework) is a fantastic idea. It
might involve a heavy amount of work but is definitely doable if we
get focused. Meanwhile, back to the subject of ext components, perhaps
many of them need to be merged and or replaced. That might include:
- securityext: not sure why it exists
- commonext: that's a difficult one, lots of entanglements, but none
the less I'm not sure why does it exist and why does it depend on
other "application" components.
- exampleext: no idea why, but probably least useful.

So following Pierre's suggestion perhaps we should generalize this
thread and consider removing all three?

On Mon, Jan 8, 2018 at 1:29 PM, Jacopo Cappellato
<[hidden email]> wrote:

> Scott is making a good point about entity-ext: in my opinion the design is
> good (but can be improved).
> I suspect that commonext and exampleext have a less clean implementation
> and maybe they do not even implement that pattern, I see less value in them.
>
> One comment on entity-ext: In my opinion we should (for this and for
> several other parts of the framework) continue the work to make the
> framework code more modular (with core independent modules and with
> extended modules that depend on them etc...) but I don't think that the
> building block should be the "OFBiz component" as it is now. It would be
> better to rely on jar files instead.
> For example:
> entity-core-api.jar
>   entity-core-impl.jar
> service-core-api.jar
>   service-core-impl.jar
>
> service-entity.jar that provides the integration of services with the
> entity engine and depends on entity-core-api.jar and service-core-api.jar
>
> We could define several granular modules that would allow to deploy
> different flavors of the framework, e.g.:
> 1) entity-core-api.jar + entity-core-impl.jar: entity engine available to
> legacy applications (built from scratch)
> 2) service-core-api.jar + service-core-impl.jar: service engine available
> to legacy applications (built from scratch)
> 3) entity-core-api.jar + entity-core-custom impl.jar: custom entity engine
> available to legacy applications (built from scratch)
> etc...
>
> Jacopo
>
> On Sun, Jan 7, 2018 at 9:55 PM, Scott Gray <[hidden email]>
> wrote:
>
>> I'm not familiar with commonext or exampleext, but the purpose of the
>> entity-ext component was to allow the entity engine to exist without the
>> service engine.  That's why all the entity-related logic that relies on the
>> service engine is implemented there (EECAs, EntitySync, DCC).  The
>> alternative would be to have that stuff in the service engine, it can't
>> exist in the entity engine because you'd have a circular compile-time
>> dependency.
>>
>> It effectively exists as a "disentanglement" of the entity and service
>> engines.
>>
>> Regards
>> Scott
>>
>>
>> On 8 January 2018 at 09:18, Taher Alkhateeb <[hidden email]>
>> wrote:
>>
>> > I think all -ext components (entityext, commonext, exampleext) are
>> > redundant and do not add value. Any patches to fix this issue and
>> > merge these components would be great.
>> >
>> >
>> >
>> > On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <[hidden email]>
>> > wrote:
>> > > Hi all,
>> > >
>> > > The ExampleExt components provides functionality to extend widgets
>> across
>> > > components. In this solution, the ExampleExt component has form widgets
>> > > extending similar widgets in the Example component.
>> > >
>> > > This kind of functionality (both within one component and across, and
>> > with
>> > > more variants) already/also exists in other components in the
>> > > ofbiz-framework code base.
>> > >
>> > > So, do we still want to entertain/maintain a component that adds little
>> > to
>> > > no unique value for our (potential) adopters, even though it is in the
>> > > ofbiz-plugin code base?
>> > >
>> > > For what it is worth: the ExampleExt widgets can easily be integrated
>> in
>> > > the Example component, and the existence of extended/extending widgets
>> in
>> > > the ofbiz-framework code base also serves as examples of what can be
>> > > achieved by adopters/contributors.
>> > >
>> > > What are your thoughts?
>> > >
>> > >
>> > > Best regards,
>> > >
>> > > Pierre Smits
>> > >
>> > > V.P. Apache Trafodion
>> > > PMC Member Apache Directory
>> >
>>

[Scott Gray-3]

My memory is vague on security-ext but I think the purpose was to extend
the security component for application-level functionality (as opposed to
framework-level). For example the UserLogin.partyId field was added to the
schema in this component because the framework wasn't supposed to have any
concept of the Party model.

Regards
Scott

On 9/01/2018 7:14 AM, "Taher Alkhateeb" <[hidden email]> wrote:

> I stand corrected, Scott made a very good point regarding entityext
> that I did not pay enough attention to. Perhaps the name is misleading
> though, entityext means an enhancement or extension of the
> capabilities of the entity component which does not make a lot of
> sense. If it was called entity-service or entity-service-map or
> something like might have been more direct and self explanatory.
>
> I think Jacopo's comment of moving away from components to jars as the
> building blocks (at least for the framework) is a fantastic idea. It
> might involve a heavy amount of work but is definitely doable if we
> get focused. Meanwhile, back to the subject of ext components, perhaps
> many of them need to be merged and or replaced. That might include:
> - securityext: not sure why it exists
> - commonext: that's a difficult one, lots of entanglements, but none
> the less I'm not sure why does it exist and why does it depend on
> other "application" components.
> - exampleext: no idea why, but probably least useful.
>
> So following Pierre's suggestion perhaps we should generalize this
> thread and consider removing all three?
>
> On Mon, Jan 8, 2018 at 1:29 PM, Jacopo Cappellato
> <[hidden email]> wrote:
> > Scott is making a good point about entity-ext: in my opinion the design
> is
> > good (but can be improved).
> > I suspect that commonext and exampleext have a less clean implementation
> > and maybe they do not even implement that pattern, I see less value in
> them.
> >
> > One comment on entity-ext: In my opinion we should (for this and for
> > several other parts of the framework) continue the work to make the
> > framework code more modular (with core independent modules and with
> > extended modules that depend on them etc...) but I don't think that the
> > building block should be the "OFBiz component" as it is now. It would be
> > better to rely on jar files instead.
> > For example:
> > entity-core-api.jar
> >   entity-core-impl.jar
> > service-core-api.jar
> >   service-core-impl.jar
> >
> > service-entity.jar that provides the integration of services with the
> > entity engine and depends on entity-core-api.jar and service-core-api.jar
> >
> > We could define several granular modules that would allow to deploy
> > different flavors of the framework, e.g.:
> > 1) entity-core-api.jar + entity-core-impl.jar: entity engine available to
> > legacy applications (built from scratch)
> > 2) service-core-api.jar + service-core-impl.jar: service engine available
> > to legacy applications (built from scratch)
> > 3) entity-core-api.jar + entity-core-custom impl.jar: custom entity
> engine
> > available to legacy applications (built from scratch)
> > etc...
> >
> > Jacopo
> >
> > On Sun, Jan 7, 2018 at 9:55 PM, Scott Gray <[hidden email]
> >
> > wrote:
> >
> >> I'm not familiar with commonext or exampleext, but the purpose of the
> >> entity-ext component was to allow the entity engine to exist without the
> >> service engine.  That's why all the entity-related logic that relies on
> the
> >> service engine is implemented there (EECAs, EntitySync, DCC).  The
> >> alternative would be to have that stuff in the service engine, it can't
> >> exist in the entity engine because you'd have a circular compile-time
> >> dependency.
> >>
> >> It effectively exists as a "disentanglement" of the entity and service
> >> engines.
> >>
> >> Regards
> >> Scott
> >>
> >>
> >> On 8 January 2018 at 09:18, Taher Alkhateeb <[hidden email]
> >
> >> wrote:
> >>
> >> > I think all -ext components (entityext, commonext, exampleext) are
> >> > redundant and do not add value. Any patches to fix this issue and
> >> > merge these components would be great.
> >> >
> >> >
> >> >
> >> > On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <[hidden email]>
> >> > wrote:
> >> > > Hi all,
> >> > >
> >> > > The ExampleExt components provides functionality to extend widgets
> >> across
> >> > > components. In this solution, the ExampleExt component has form
> widgets
> >> > > extending similar widgets in the Example component.
> >> > >
> >> > > This kind of functionality (both within one component and across,
> and
> >> > with
> >> > > more variants) already/also exists in other components in the
> >> > > ofbiz-framework code base.
> >> > >
> >> > > So, do we still want to entertain/maintain a component that adds
> little
> >> > to
> >> > > no unique value for our (potential) adopters, even though it is in
> the
> >> > > ofbiz-plugin code base?
> >> > >
> >> > > For what it is worth: the ExampleExt widgets can easily be
> integrated
> >> in
> >> > > the Example component, and the existence of extended/extending
> widgets
> >> in
> >> > > the ofbiz-framework code base also serves as examples of what can be
> >> > > achieved by adopters/contributors.
> >> > >
> >> > > What are your thoughts?
> >> > >
> >> > >
> >> > > Best regards,
> >> > >
> >> > > Pierre Smits
> >> > >
> >> > > V.P. Apache Trafodion
> >> > > PMC Member Apache Directory
> >> >
> >>
>

[Jacques Le Roux]

That makes sense, thanks Scott

Jacques


Le 08/01/2018 à 19:51, Scott Gray a écrit :

> My memory is vague on security-ext but I think the purpose was to extend
> the security component for application-level functionality (as opposed to
> framework-level). For example the UserLogin.partyId field was added to the
> schema in this component because the framework wasn't supposed to have any
> concept of the Party model.
>
> Regards
> Scott
>
> On 9/01/2018 7:14 AM, "Taher Alkhateeb" <[hidden email]> wrote:
>
>> I stand corrected, Scott made a very good point regarding entityext
>> that I did not pay enough attention to. Perhaps the name is misleading
>> though, entityext means an enhancement or extension of the
>> capabilities of the entity component which does not make a lot of
>> sense. If it was called entity-service or entity-service-map or
>> something like might have been more direct and self explanatory.
>>
>> I think Jacopo's comment of moving away from components to jars as the
>> building blocks (at least for the framework) is a fantastic idea. It
>> might involve a heavy amount of work but is definitely doable if we
>> get focused. Meanwhile, back to the subject of ext components, perhaps
>> many of them need to be merged and or replaced. That might include:
>> - securityext: not sure why it exists
>> - commonext: that's a difficult one, lots of entanglements, but none
>> the less I'm not sure why does it exist and why does it depend on
>> other "application" components.
>> - exampleext: no idea why, but probably least useful.
>>
>> So following Pierre's suggestion perhaps we should generalize this
>> thread and consider removing all three?
>>
>> On Mon, Jan 8, 2018 at 1:29 PM, Jacopo Cappellato
>> <[hidden email]> wrote:
>>> Scott is making a good point about entity-ext: in my opinion the design
>> is
>>> good (but can be improved).
>>> I suspect that commonext and exampleext have a less clean implementation
>>> and maybe they do not even implement that pattern, I see less value in
>> them.
>>> One comment on entity-ext: In my opinion we should (for this and for
>>> several other parts of the framework) continue the work to make the
>>> framework code more modular (with core independent modules and with
>>> extended modules that depend on them etc...) but I don't think that the
>>> building block should be the "OFBiz component" as it is now. It would be
>>> better to rely on jar files instead.
>>> For example:
>>> entity-core-api.jar
>>>    entity-core-impl.jar
>>> service-core-api.jar
>>>    service-core-impl.jar
>>>
>>> service-entity.jar that provides the integration of services with the
>>> entity engine and depends on entity-core-api.jar and service-core-api.jar
>>>
>>> We could define several granular modules that would allow to deploy
>>> different flavors of the framework, e.g.:
>>> 1) entity-core-api.jar + entity-core-impl.jar: entity engine available to
>>> legacy applications (built from scratch)
>>> 2) service-core-api.jar + service-core-impl.jar: service engine available
>>> to legacy applications (built from scratch)
>>> 3) entity-core-api.jar + entity-core-custom impl.jar: custom entity
>> engine
>>> available to legacy applications (built from scratch)
>>> etc...
>>>
>>> Jacopo
>>>
>>> On Sun, Jan 7, 2018 at 9:55 PM, Scott Gray <[hidden email]
>>>
>>> wrote:
>>>
>>>> I'm not familiar with commonext or exampleext, but the purpose of the
>>>> entity-ext component was to allow the entity engine to exist without the
>>>> service engine.  That's why all the entity-related logic that relies on
>> the
>>>> service engine is implemented there (EECAs, EntitySync, DCC).  The
>>>> alternative would be to have that stuff in the service engine, it can't
>>>> exist in the entity engine because you'd have a circular compile-time
>>>> dependency.
>>>>
>>>> It effectively exists as a "disentanglement" of the entity and service
>>>> engines.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>>
>>>> On 8 January 2018 at 09:18, Taher Alkhateeb <[hidden email]
>>>> wrote:
>>>>
>>>>> I think all -ext components (entityext, commonext, exampleext) are
>>>>> redundant and do not add value. Any patches to fix this issue and
>>>>> merge these components would be great.
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <[hidden email]>
>>>>> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> The ExampleExt components provides functionality to extend widgets
>>>> across
>>>>>> components. In this solution, the ExampleExt component has form
>> widgets
>>>>>> extending similar widgets in the Example component.
>>>>>>
>>>>>> This kind of functionality (both within one component and across,
>> and
>>>>> with
>>>>>> more variants) already/also exists in other components in the
>>>>>> ofbiz-framework code base.
>>>>>>
>>>>>> So, do we still want to entertain/maintain a component that adds
>> little
>>>>> to
>>>>>> no unique value for our (potential) adopters, even though it is in
>> the
>>>>>> ofbiz-plugin code base?
>>>>>>
>>>>>> For what it is worth: the ExampleExt widgets can easily be
>> integrated
>>>> in
>>>>>> the Example component, and the existence of extended/extending
>> widgets
>>>> in
>>>>>> the ofbiz-framework code base also serves as examples of what can be
>>>>>> achieved by adopters/contributors.
>>>>>>
>>>>>> What are your thoughts?
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Pierre Smits
>>>>>>
>>>>>> V.P. Apache Trafodion
>>>>>> PMC Member Apache Directory

[Jacques Le Roux]

Certainly an ambitious but interesting idea


Le 08/01/2018 à 11:29, Jacopo Cappellato a écrit :

> Scott is making a good point about entity-ext: in my opinion the design is
> good (but can be improved).
> I suspect that commonext and exampleext have a less clean implementation
> and maybe they do not even implement that pattern, I see less value in them.
>
> One comment on entity-ext: In my opinion we should (for this and for
> several other parts of the framework) continue the work to make the
> framework code more modular (with core independent modules and with
> extended modules that depend on them etc...) but I don't think that the
> building block should be the "OFBiz component" as it is now. It would be
> better to rely on jar files instead.
> For example:
> entity-core-api.jar
>    entity-core-impl.jar
> service-core-api.jar
>    service-core-impl.jar
>
> service-entity.jar that provides the integration of services with the
> entity engine and depends on entity-core-api.jar and service-core-api.jar
>
> We could define several granular modules that would allow to deploy
> different flavors of the framework, e.g.:
> 1) entity-core-api.jar + entity-core-impl.jar: entity engine available to
> legacy applications (built from scratch)
> 2) service-core-api.jar + service-core-impl.jar: service engine available
> to legacy applications (built from scratch)
> 3) entity-core-api.jar + entity-core-custom impl.jar: custom entity engine
> available to legacy applications (built from scratch)
> etc...
>
> Jacopo
>
> On Sun, Jan 7, 2018 at 9:55 PM, Scott Gray <[hidden email]>
> wrote:
>
>> I'm not familiar with commonext or exampleext, but the purpose of the
>> entity-ext component was to allow the entity engine to exist without the
>> service engine.  That's why all the entity-related logic that relies on the
>> service engine is implemented there (EECAs, EntitySync, DCC).  The
>> alternative would be to have that stuff in the service engine, it can't
>> exist in the entity engine because you'd have a circular compile-time
>> dependency.
>>
>> It effectively exists as a "disentanglement" of the entity and service
>> engines.
>>
>> Regards
>> Scott
>>
>>
>> On 8 January 2018 at 09:18, Taher Alkhateeb <[hidden email]>
>> wrote:
>>
>>> I think all -ext components (entityext, commonext, exampleext) are
>>> redundant and do not add value. Any patches to fix this issue and
>>> merge these components would be great.
>>>
>>>
>>>
>>> On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <[hidden email]>
>>> wrote:
>>>> Hi all,
>>>>
>>>> The ExampleExt components provides functionality to extend widgets
>> across
>>>> components. In this solution, the ExampleExt component has form widgets
>>>> extending similar widgets in the Example component.
>>>>
>>>> This kind of functionality (both within one component and across, and
>>> with
>>>> more variants) already/also exists in other components in the
>>>> ofbiz-framework code base.
>>>>
>>>> So, do we still want to entertain/maintain a component that adds little
>>> to
>>>> no unique value for our (potential) adopters, even though it is in the
>>>> ofbiz-plugin code base?
>>>>
>>>> For what it is worth: the ExampleExt widgets can easily be integrated
>> in
>>>> the Example component, and the existence of extended/extending widgets
>> in
>>>> the ofbiz-framework code base also serves as examples of what can be
>>>> achieved by adopters/contributors.
>>>>
>>>> What are your thoughts?
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> V.P. Apache Trafodion
>>>> PMC Member Apache Directory

[Jacques Le Roux]

Hi Taher, All,

Scott made another good point on party for the reason of the existence of securityext

I'll try to summarise where we are so far:

  * Both entityext and securityext have intrinsic value. They could be improved but a priori not removed and then specific Jiras should be created.
  * exampleext could me merged with example or simply removed (to be verified). In both cases, some documentation about what it (pitifully I must say)
    tries to show should be created, preferably as a README.md in example component. A specific ticket should be created for that

Agreed?

Jacques


Le 08/01/2018 à 19:14, Taher Alkhateeb a écrit :

> I stand corrected, Scott made a very good point regarding entityext
> that I did not pay enough attention to. Perhaps the name is misleading
> though, entityext means an enhancement or extension of the
> capabilities of the entity component which does not make a lot of
> sense. If it was called entity-service or entity-service-map or
> something like might have been more direct and self explanatory.
>
> I think Jacopo's comment of moving away from components to jars as the
> building blocks (at least for the framework) is a fantastic idea. It
> might involve a heavy amount of work but is definitely doable if we
> get focused. Meanwhile, back to the subject of ext components, perhaps
> many of them need to be merged and or replaced. That might include:
> - securityext: not sure why it exists
> - commonext: that's a difficult one, lots of entanglements, but none
> the less I'm not sure why does it exist and why does it depend on
> other "application" components.
> - exampleext: no idea why, but probably least useful.
>
> So following Pierre's suggestion perhaps we should generalize this
> thread and consider removing all three?
>
> On Mon, Jan 8, 2018 at 1:29 PM, Jacopo Cappellato
> <[hidden email]> wrote:
>> Scott is making a good point about entity-ext: in my opinion the design is
>> good (but can be improved).
>> I suspect that commonext and exampleext have a less clean implementation
>> and maybe they do not even implement that pattern, I see less value in them.
>>
>> One comment on entity-ext: In my opinion we should (for this and for
>> several other parts of the framework) continue the work to make the
>> framework code more modular (with core independent modules and with
>> extended modules that depend on them etc...) but I don't think that the
>> building block should be the "OFBiz component" as it is now. It would be
>> better to rely on jar files instead.
>> For example:
>> entity-core-api.jar
>>    entity-core-impl.jar
>> service-core-api.jar
>>    service-core-impl.jar
>>
>> service-entity.jar that provides the integration of services with the
>> entity engine and depends on entity-core-api.jar and service-core-api.jar
>>
>> We could define several granular modules that would allow to deploy
>> different flavors of the framework, e.g.:
>> 1) entity-core-api.jar + entity-core-impl.jar: entity engine available to
>> legacy applications (built from scratch)
>> 2) service-core-api.jar + service-core-impl.jar: service engine available
>> to legacy applications (built from scratch)
>> 3) entity-core-api.jar + entity-core-custom impl.jar: custom entity engine
>> available to legacy applications (built from scratch)
>> etc...
>>
>> Jacopo
>>
>> On Sun, Jan 7, 2018 at 9:55 PM, Scott Gray <[hidden email]>
>> wrote:
>>
>>> I'm not familiar with commonext or exampleext, but the purpose of the
>>> entity-ext component was to allow the entity engine to exist without the
>>> service engine.  That's why all the entity-related logic that relies on the
>>> service engine is implemented there (EECAs, EntitySync, DCC).  The
>>> alternative would be to have that stuff in the service engine, it can't
>>> exist in the entity engine because you'd have a circular compile-time
>>> dependency.
>>>
>>> It effectively exists as a "disentanglement" of the entity and service
>>> engines.
>>>
>>> Regards
>>> Scott
>>>
>>>
>>> On 8 January 2018 at 09:18, Taher Alkhateeb <[hidden email]>
>>> wrote:
>>>
>>>> I think all -ext components (entityext, commonext, exampleext) are
>>>> redundant and do not add value. Any patches to fix this issue and
>>>> merge these components would be great.
>>>>
>>>>
>>>>
>>>> On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <[hidden email]>
>>>> wrote:
>>>>> Hi all,
>>>>>
>>>>> The ExampleExt components provides functionality to extend widgets
>>> across
>>>>> components. In this solution, the ExampleExt component has form widgets
>>>>> extending similar widgets in the Example component.
>>>>>
>>>>> This kind of functionality (both within one component and across, and
>>>> with
>>>>> more variants) already/also exists in other components in the
>>>>> ofbiz-framework code base.
>>>>>
>>>>> So, do we still want to entertain/maintain a component that adds little
>>>> to
>>>>> no unique value for our (potential) adopters, even though it is in the
>>>>> ofbiz-plugin code base?
>>>>>
>>>>> For what it is worth: the ExampleExt widgets can easily be integrated
>>> in
>>>>> the Example component, and the existence of extended/extending widgets
>>> in
>>>>> the ofbiz-framework code base also serves as examples of what can be
>>>>> achieved by adopters/contributors.
>>>>>
>>>>> What are your thoughts?
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> V.P. Apache Trafodion
>>>>> PMC Member Apache Directory

[James Yong-2]

Hi all,

IMO, it may be better to improve upon ExampleExt to show how to extend/override the entities, services, screens, forms, events from Example component. This will help developers to implement OFBiz solutions correctly and make future upgrades possible.

Regards,
James Yong

On 2018-01-09 18:44, Jacques Le Roux <[hidden email]> wrote:

> Hi Taher, All,
>
> Scott made another good point on party for the reason of the existence of securityext
>
> I'll try to summarise where we are so far:
>
>   * Both entityext and securityext have intrinsic value. They could be improved but a priori not removed and then specific Jiras should be created.
>   * exampleext could me merged with example or simply removed (to be verified). In both cases, some documentation about what it (pitifully I must say)
>     tries to show should be created, preferably as a README.md in example component. A specific ticket should be created for that
>
> Agreed?
>
> Jacques
>
>
> Le 08/01/2018 à 19:14, Taher Alkhateeb a écrit :
> > I stand corrected, Scott made a very good point regarding entityext
> > that I did not pay enough attention to. Perhaps the name is misleading
> > though, entityext means an enhancement or extension of the
> > capabilities of the entity component which does not make a lot of
> > sense. If it was called entity-service or entity-service-map or
> > something like might have been more direct and self explanatory.
> >
> > I think Jacopo's comment of moving away from components to jars as the
> > building blocks (at least for the framework) is a fantastic idea. It
> > might involve a heavy amount of work but is definitely doable if we
> > get focused. Meanwhile, back to the subject of ext components, perhaps
> > many of them need to be merged and or replaced. That might include:
> > - securityext: not sure why it exists
> > - commonext: that's a difficult one, lots of entanglements, but none
> > the less I'm not sure why does it exist and why does it depend on
> > other "application" components.
> > - exampleext: no idea why, but probably least useful.
> >
> > So following Pierre's suggestion perhaps we should generalize this
> > thread and consider removing all three?
> >
> > On Mon, Jan 8, 2018 at 1:29 PM, Jacopo Cappellato
> > <[hidden email]> wrote:
> >> Scott is making a good point about entity-ext: in my opinion the design is
> >> good (but can be improved).
> >> I suspect that commonext and exampleext have a less clean implementation
> >> and maybe they do not even implement that pattern, I see less value in them.
> >>
> >> One comment on entity-ext: In my opinion we should (for this and for
> >> several other parts of the framework) continue the work to make the
> >> framework code more modular (with core independent modules and with
> >> extended modules that depend on them etc...) but I don't think that the
> >> building block should be the "OFBiz component" as it is now. It would be
> >> better to rely on jar files instead.
> >> For example:
> >> entity-core-api.jar
> >>    entity-core-impl.jar
> >> service-core-api.jar
> >>    service-core-impl.jar
> >>
> >> service-entity.jar that provides the integration of services with the
> >> entity engine and depends on entity-core-api.jar and service-core-api.jar
> >>
> >> We could define several granular modules that would allow to deploy
> >> different flavors of the framework, e.g.:
> >> 1) entity-core-api.jar + entity-core-impl.jar: entity engine available to
> >> legacy applications (built from scratch)
> >> 2) service-core-api.jar + service-core-impl.jar: service engine available
> >> to legacy applications (built from scratch)
> >> 3) entity-core-api.jar + entity-core-custom impl.jar: custom entity engine
> >> available to legacy applications (built from scratch)
> >> etc...
> >>
> >> Jacopo
> >>
> >> On Sun, Jan 7, 2018 at 9:55 PM, Scott Gray <[hidden email]>
> >> wrote:
> >>
> >>> I'm not familiar with commonext or exampleext, but the purpose of the
> >>> entity-ext component was to allow the entity engine to exist without the
> >>> service engine.  That's why all the entity-related logic that relies on the
> >>> service engine is implemented there (EECAs, EntitySync, DCC).  The
> >>> alternative would be to have that stuff in the service engine, it can't
> >>> exist in the entity engine because you'd have a circular compile-time
> >>> dependency.
> >>>
> >>> It effectively exists as a "disentanglement" of the entity and service
> >>> engines.
> >>>
> >>> Regards
> >>> Scott
> >>>
> >>>
> >>> On 8 January 2018 at 09:18, Taher Alkhateeb <[hidden email]>
> >>> wrote:
> >>>
> >>>> I think all -ext components (entityext, commonext, exampleext) are
> >>>> redundant and do not add value. Any patches to fix this issue and
> >>>> merge these components would be great.
> >>>>
> >>>>
> >>>>
> >>>> On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <[hidden email]>
> >>>> wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> The ExampleExt components provides functionality to extend widgets
> >>> across
> >>>>> components. In this solution, the ExampleExt component has form widgets
> >>>>> extending similar widgets in the Example component.
> >>>>>
> >>>>> This kind of functionality (both within one component and across, and
> >>>> with
> >>>>> more variants) already/also exists in other components in the
> >>>>> ofbiz-framework code base.
> >>>>>
> >>>>> So, do we still want to entertain/maintain a component that adds little
> >>>> to
> >>>>> no unique value for our (potential) adopters, even though it is in the
> >>>>> ofbiz-plugin code base?
> >>>>>
> >>>>> For what it is worth: the ExampleExt widgets can easily be integrated
> >>> in
> >>>>> the Example component, and the existence of extended/extending widgets
> >>> in
> >>>>> the ofbiz-framework code base also serves as examples of what can be
> >>>>> achieved by adopters/contributors.
> >>>>>
> >>>>> What are your thoughts?
> >>>>>
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Pierre Smits
> >>>>>
> >>>>> V.P. Apache Trafodion
> >>>>> PMC Member Apache Directory
>
>

[Jacques Le Roux]

Yes also, it's all about documenting IMO, either inside the component (my preference, either merged with example - not my preference again no not mix
things, outside only (not my preference, blur things, using inside doc outside is OK IMO) or even w/o (which even less my preference)

We have a saying in French: "Whoever wants to drown his dog accuses him of rage". Here the dog is the exampleext component, not sure why we want to
drown it, apart that it lacks documentation.

Jacques


Le 09/01/2018 à 15:37, James Yong a écrit :

> Hi all,
>
> IMO, it may be better to improve upon ExampleExt to show how to extend/override the entities, services, screens, forms, events from Example component. This will help developers to implement OFBiz solutions correctly and make future upgrades possible.
>
> Regards,
> James Yong
>
> On 2018-01-09 18:44, Jacques Le Roux <[hidden email]> wrote:
>> Hi Taher, All,
>>
>> Scott made another good point on party for the reason of the existence of securityext
>>
>> I'll try to summarise where we are so far:
>>
>>    * Both entityext and securityext have intrinsic value. They could be improved but a priori not removed and then specific Jiras should be created.
>>    * exampleext could me merged with example or simply removed (to be verified). In both cases, some documentation about what it (pitifully I must say)
>>      tries to show should be created, preferably as a README.md in example component. A specific ticket should be created for that
>>
>> Agreed?
>>
>> Jacques
>>
>>
>> Le 08/01/2018 à 19:14, Taher Alkhateeb a écrit :
>>> I stand corrected, Scott made a very good point regarding entityext
>>> that I did not pay enough attention to. Perhaps the name is misleading
>>> though, entityext means an enhancement or extension of the
>>> capabilities of the entity component which does not make a lot of
>>> sense. If it was called entity-service or entity-service-map or
>>> something like might have been more direct and self explanatory.
>>>
>>> I think Jacopo's comment of moving away from components to jars as the
>>> building blocks (at least for the framework) is a fantastic idea. It
>>> might involve a heavy amount of work but is definitely doable if we
>>> get focused. Meanwhile, back to the subject of ext components, perhaps
>>> many of them need to be merged and or replaced. That might include:
>>> - securityext: not sure why it exists
>>> - commonext: that's a difficult one, lots of entanglements, but none
>>> the less I'm not sure why does it exist and why does it depend on
>>> other "application" components.
>>> - exampleext: no idea why, but probably least useful.
>>>
>>> So following Pierre's suggestion perhaps we should generalize this
>>> thread and consider removing all three?
>>>
>>> On Mon, Jan 8, 2018 at 1:29 PM, Jacopo Cappellato
>>> <[hidden email]> wrote:
>>>> Scott is making a good point about entity-ext: in my opinion the design is
>>>> good (but can be improved).
>>>> I suspect that commonext and exampleext have a less clean implementation
>>>> and maybe they do not even implement that pattern, I see less value in them.
>>>>
>>>> One comment on entity-ext: In my opinion we should (for this and for
>>>> several other parts of the framework) continue the work to make the
>>>> framework code more modular (with core independent modules and with
>>>> extended modules that depend on them etc...) but I don't think that the
>>>> building block should be the "OFBiz component" as it is now. It would be
>>>> better to rely on jar files instead.
>>>> For example:
>>>> entity-core-api.jar
>>>>     entity-core-impl.jar
>>>> service-core-api.jar
>>>>     service-core-impl.jar
>>>>
>>>> service-entity.jar that provides the integration of services with the
>>>> entity engine and depends on entity-core-api.jar and service-core-api.jar
>>>>
>>>> We could define several granular modules that would allow to deploy
>>>> different flavors of the framework, e.g.:
>>>> 1) entity-core-api.jar + entity-core-impl.jar: entity engine available to
>>>> legacy applications (built from scratch)
>>>> 2) service-core-api.jar + service-core-impl.jar: service engine available
>>>> to legacy applications (built from scratch)
>>>> 3) entity-core-api.jar + entity-core-custom impl.jar: custom entity engine
>>>> available to legacy applications (built from scratch)
>>>> etc...
>>>>
>>>> Jacopo
>>>>
>>>> On Sun, Jan 7, 2018 at 9:55 PM, Scott Gray <[hidden email]>
>>>> wrote:
>>>>
>>>>> I'm not familiar with commonext or exampleext, but the purpose of the
>>>>> entity-ext component was to allow the entity engine to exist without the
>>>>> service engine.  That's why all the entity-related logic that relies on the
>>>>> service engine is implemented there (EECAs, EntitySync, DCC).  The
>>>>> alternative would be to have that stuff in the service engine, it can't
>>>>> exist in the entity engine because you'd have a circular compile-time
>>>>> dependency.
>>>>>
>>>>> It effectively exists as a "disentanglement" of the entity and service
>>>>> engines.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>>
>>>>> On 8 January 2018 at 09:18, Taher Alkhateeb <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> I think all -ext components (entityext, commonext, exampleext) are
>>>>>> redundant and do not add value. Any patches to fix this issue and
>>>>>> merge these components would be great.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Jan 7, 2018 at 9:38 PM, Pierre Smits <[hidden email]>
>>>>>> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> The ExampleExt components provides functionality to extend widgets
>>>>> across
>>>>>>> components. In this solution, the ExampleExt component has form widgets
>>>>>>> extending similar widgets in the Example component.
>>>>>>>
>>>>>>> This kind of functionality (both within one component and across, and
>>>>>> with
>>>>>>> more variants) already/also exists in other components in the
>>>>>>> ofbiz-framework code base.
>>>>>>>
>>>>>>> So, do we still want to entertain/maintain a component that adds little
>>>>>> to
>>>>>>> no unique value for our (potential) adopters, even though it is in the
>>>>>>> ofbiz-plugin code base?
>>>>>>>
>>>>>>> For what it is worth: the ExampleExt widgets can easily be integrated
>>>>> in
>>>>>>> the Example component, and the existence of extended/extending widgets
>>>>> in
>>>>>>> the ofbiz-framework code base also serves as examples of what can be
>>>>>>> achieved by adopters/contributors.
>>>>>>>
>>>>>>> What are your thoughts?
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Pierre Smits
>>>>>>>
>>>>>>> V.P. Apache Trafodion
>>>>>>> PMC Member Apache Directory
>>

[Jacques Le Roux]

Le 08/01/2018 à 19:14, Taher Alkhateeb a écrit :
> - commonext: that's a difficult one, lots of entanglements, but none
> the less I'm not sure why does it exist and why does it depend on
> other "application" components.
While looking to close old Jiras I stumbled upon https://issues.apache.org/jira/browse/OFBIZ-3329
There is a discussion there about commonext and why it exists

Actually my questions here are:

 1. Should we not close OFBIZ-3329
 2. Should we not create Jiras for handling changes related to commonext and exampleext

I noticed discussions not followed by action (at least Jiras creation, or even closing) are useless as they almost sublimate in the void.

Jacques

[Pierre Smits-3]

> I noticed discussions not followed by action (at least Jiras creation, or
> even closing) are useless as they almost sublimate in the void.
>
> Jacques
>
>
How unfortunate. But when each comment added inserts a (new) viewpoint
about other aspects of the code base, then it is very hard for each
participant in this project to determine what kind of contribution will be
most beneficial to the project. Confusion leads to stagnation.

Best regards,

Pierre

[Jacques Le Roux]

We have lazy consensus and vote for that.

But after them we still need action. I keep note about things I want to do. Sometimes it happens years after, and I have also seen others doing things
I waited for years. It warms my heart then :)

Just an human

Jacques


Le 27/01/2018 à 16:00, Pierre Smits a écrit :

>> I noticed discussions not followed by action (at least Jiras creation, or
>> even closing) are useless as they almost sublimate in the void.
>>
>> Jacques
>>
>>
> How unfortunate. But when each comment added inserts a (new) viewpoint
> about other aspects of the code base, then it is very hard for each
> participant in this project to determine what kind of contribution will be
> most beneficial to the project. Confusion leads to stagnation.
>
> Best regards,
>
> Pierre
>