On Nov 23, 2014, at 8:44 PM, Pierre Smits <[email protected]> wrote:
> Jacopo, All, > > You and I are in sync here, with respect to how the components in the > various levels stack up to be the primary work of the OFBiz project. I also > agree that this can be achieved in a reasonable amount of time and effort > spent. +1 > > Having svn repositories per layer plays into this approach. The main advantage is that initially there is no need to modify the layout of the current svn (trunk and branches): * the work required will be only that of fixing the dependencies between components * then users should be able to checkout the branch they like and remove the layers they do not want and then build OFBiz successfully (e.g. with framework only OR framework+core OR framework+core+applications/specialpurpose) * at a later time we could discuss if we also want to provide separate releases/download for the framework, the core, the applications/specialpurpose but until that time we will continue to release the whole package as it happens now > That also helps > to attract more committers (regarding code) so that this project retains > the level of quality it requires. And it seems to be inline to what Ron is > trying to bring across. > > But this approach will only work if we all consent to it. +1 Best regards, Jacopo > > Best 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 7:37 PM, Jacopo Cappellato < > [email protected]> wrote: > >> 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 <[email protected]> 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 < >>> [email protected]> 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 >>>> >>>> >> >>
