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 <jacopo.cappell...@hotwaxsystems.com> 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 <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 >> > >>
