Hi Taher, what you describe seems to be inline with the concept of having commonext as the base component for all the applications (i.e. loaded first): all applications will depend on it and would use (for example) its labels. Am I missing something?
Jacopo On Nov 24, 2014, at 10:19 AM, Taher Alkhateeb <[email protected]> wrote: > Hi Jacopo and Pierre, > > I like the idea of the new design but it will represent some problems which > we need to think about. For example, the commonext prepares the UI labels > which are commonly used (content, party, etc ...) and makes them available > across all components. This makes a dependency from commonext to the > components. If you remove this dependency then you have to prepare the UI > labels for each component separately in its CommonScreens.xml. Not a lot of > work but you do end-up repeating yourself a bit. > > So some code needs to be removed from commonext to the higher level > applications to allow for your vision described earlier in this thread. > > Taher Alkhateeb > > On Mon, Nov 24, 2014 at 9:05 AM, Jacopo Cappellato < > [email protected]> wrote: > >> >> 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 >>>>>> >>>>>> >>>> >>>> >> >>
