Thanks Pierre for the description. My goal is not actually that of removing an unused component, but instead trying to come up with an architecture that with little effort and no major changes would let us deliver the following products:
*OFBiz framework* Structure: it includes only the framework components, the tools, hot-deploy and runtime folders; only a few entities are defined (the ones declared by the framework components, of course); no applications, no specialpurpose; the only user interface available ootb is WebTools. Purpose: provide a framework to build ERP-like applications from scratch; typically a developer will start by running the "ant create-component" task and will then declare the entities, services and screens in the custom component *OFBiz core* Structure: it contains one application component (this could be the commonext component, after it has been cleaned up) that only contains all the entity definitions (the whole data model) that are currently defined in the various applications; it will also include CRUD or basic and very global/generic services; no user interfaces Purpose: to be used with the "OFBiz framework" by users interested in building from scratch user interfaces based on the OFBiz data model and crud services *OFBiz applications* Structure: it contains all the existing applications (except the component delivered as "OFBiz core") with their special services and user interfaces Purpose: to be used by users interested to running a mostly-ready out of the box solution; to be used with the "OFBiz framework" and "OFBiz core" *OFBiz specialpurpose* Structure: it contains all the existing specialpurpose components with their special services and user interfaces Purpose: to be used by users interested in specific integrations/solutions solution; to be used with the "OFBiz framework" and (maybe) "OFBiz core"; the user could use a subset of the specialpurpose components What we currently call "Apache OFBiz" would be the sum of the following products: "OFBiz framework" + "OFBiz core" + "OFBiz applications" + "OFBiz specialpurpose" We could even merge together "OFBiz applications" and "OFBiz specialpurpose" into one group, the applications, if we can provide some good way to represent the dependencies among them: we could let the user decide which components should be enabled. I am convinced that we could achieve this goal with a reasonable effort and this could be a first step in the direction of making OFBiz more modular; we could then design and implement further improvements. Jacopo On Nov 23, 2014, at 1:01 PM, Pierre Smits <pierre.sm...@gmail.com> wrote: > Hi all, > > IIRW, components like commonext, securityext and entityext were constructed > and implemented by the community to enable developers (users/contributors) > to extend the functionalities in lower level components (services et al) > and create commonalities that can be shared between components on the same > and/or higher level, so that the lower level functionalities change as > little as possible. > > Thus leading to: > > - hot--deploy extends (and/or uses) hot-deploy, special purpose, apps & > framework components > - special purpose extends (and/or uses) special purpose, apps & > framework components > - apps extends (and/or uses) apps & framework components > - framework extends (and/or uses) framework components > > Examples are: > Manufacturing extends workeffort, party, etc > ProjectMgr extends workeffort, party, etc > > Such a paradigm is easy to understand, and creates the least amount of > confusion (for the developer, tester, etc) when having to resolve issues > relating to dependencies. If and when we move a lower level component to a > higher lever, we increase this confusion. This should be avoided as much as > possible, because removing the confusion leads to (more) rework. > > As Taher explained in his posting there are same and higher level > dependencies on commonext. Reworking that, in order to maintain the > paradigm described above, will require a lot of effort and takes a lot of > time to have it completed. Are we willing to go there? Can we achieve that > in a reasonable amount of time? Is that needed? > > We haven't seen many contributions to this component. That is true. It is a > placeholder, provided by this community, that enables each users to extend > for their own purposes. Period. > That no enhancements/improvements to this component make their way back > into the project may indicate two things: > > 1. The component works perfectly regarding its intent. > 2. People don't feel the need to share what they have in their own > version > > Re 1: Kudos to all who have come up with the paradigm and have it > implemented in OFBiz. > > Re 2: Maybe that is because what is share regarding this is included in the > OFBiz code as an enhancement to a component on a lower level. Maybe that is > because what the individual user has in his component is subject to an NDA. > Or the user believes that what he has is so specific that he considers that > functionality of totally no use for others. > Such are the facts of life, and I accept that. This is the prerogative that > each of us has! > > So, let it be where it is and don't worry about it. Cost of maintenance (as > it is) is low. > > And the above applies to securityext as well. > > Now, if there is a dependency on a higher level component (and there is one > in this component, IIRW), we - as the community - should fix this specific > issue. That would indicate that we move stuff from lower to higher. > If the component has stuff that we feel is better to have in another > component on the same level, we can fix that too. When talking about the > NoteData entity (and accompanying functions), I believe we should have this > moved to content. > > But what about entityext? > Following the paradigm outlined above, this shouldn't be in framework, but > at the next higher level (apps). Shouldn't we move that one? > > And what about the other components in framework, that enables users to > interact with OFBiz? We have webtools containing stuff regarding base data > manipulation feature, and more. Shouldn't that move to apps (or higher) as > well? Like I initiated with > > On the other hand, we have a component in special purpose that extends base > authentication and integration. This component is called ldap. Shouldn't > functionalities in there move to the lowest level? > > And shouldn't we move the functionalities in the lucene component in > special purpose move to the apps level? It seems to be a better fit there. > > My apologies for the lengthiness of this post. Couldn't do it in a shorter > way. Anyway, a clear and shared vision helps us all. Discussing pros and > cons of viewpoints help to get there. > > Regards, > > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Sun, Nov 23, 2014 at 8:26 AM, Jacopo Cappellato < > jacopo.cappell...@hotwaxmedia.com> wrote: > >> Do you agree that specialpurpose would be a better fit for the commonext >> component that is currently under the applications folder? >> It extends the default data model adding new fields to the NoteData entity >> and provides some special purpose features. >> >> Jacopo >> >>
