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 <scott.g...@hotwaxsystems.com> 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 <slidingfilame...@gmail.com> > 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 <pierresm...@apache.org> > > 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 > > >
