Hi Jacopo, You are not missing anything! I am just stating that work needs to be done to help implementing your vision. One such example being removing the UI Label loading from the commonext to the upper application components. In fact, if you wish to open a JIRA to that effect I can help with some patches if you need that.
Regards, Taher Alkhateeb On Mon, Nov 24, 2014 at 12:40 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxmedia.com> wrote: > 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 <slidingfilame...@gmail.com> > 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 < > > jacopo.cappell...@hotwaxmedia.com> wrote: > > > >> > >> On Nov 23, 2014, at 8:44 PM, Pierre Smits <pierre.sm...@gmail.com> > 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 < > >>> jacopo.cappell...@hotwaxmedia.com> 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 <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 > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
