In my opinion, it sounds like a too fragmented approach. Better to have a core that includes everything that the base framework needs to function, and then everything else is a plug-in, with dependencies handled as required. Then the end-user can choose what plug-ins to run on the framework; if they just want to use OFBiz as an accounting application, then they install the framework core, the accounting application plug-in, and it's dependencies. ++ if this can be done semi-automatically via an extensions manager in the framework, similar to NUGET for Visual Studio.
We will see what happens if this actually happens, but my assessment, based on mail list activity, is the applications would stagnate, and devs will only focus on the core. Which would be a shame, because most of the usefulness of OFBiz, is in the applications. There are lots of other frameworks that handle application core logic and data persistence, that are easier to use to develop a business application. OFBiz's attraction is it already has pre-built ERP modules for an organization to get started with. FWIW, Tim ________________________________ From: Taher Alkhateeb <slidingfilame...@gmail.com> Sent: Monday, February 19, 2018 11:48 AM To: email@example.com Subject: Re: ofbiz framework component in trunk is misleading? Aha I see, thank you for the explanation Paul. Ok to put some clarity, we had a good discussion on the development mailing list before making the split, and this is only the first step (split plugins out). The next step we might take is to also split out the applications. That is why we called it ofbiz-framework. If everything goes as discussed and community approves, we will probably end up with 3+ repositories as follows: - ofbiz-framework: infrastructure and execution engine, and low level stuff. - ofbiz-core: the data model library, the service library, shared resource (common stuff) - Maybe an applications layer for complete usable apps - ofbiz-plugins: perhaps even each plugin in its own repository This layered architecture would help us in creating a robust code base by isolating things from each other and to allow for multiple combinations. So you can reuse the entities, services, and basic screens in different ways without duplication. Still a work in progress, but I hope this sheds some light on the naming, and sorry for any confusion regarding that. Perhaps we'll add this information to the documentation project. On Mon, Feb 19, 2018 at 2:00 PM, Paul Foxworthy <p...@cohsoft.com.au> wrote: > On 19 February 2018 at 09:32, Jim S <jim61...@gmail.com> wrote: > >> I was under impression that it is framework only component. I tried doing >> search but >> could not find much. Could someone please help provide a link to the >> discussion that leads to the current structure in trunk that might list the >> advantage of doing it? >> > > Hi Jim, > > For many years there was only one OFBiz project. When plugins were split > out into a separate repository, the remaining code was named > ofbiz-framework. Really it's applications plus framework, but that's a bit > long winded. > > Cheers > > Paul Foxworthy > > -- > Coherent Software Australia Pty Ltd > PO Box 2773 > Cheltenham Vic 3192 > Australia > > Phone: +61 3 9585 6788 > Web: http://www.coherentsoftware.com.au/ Coherent Software - Custom software,web application and ...<http://www.coherentsoftware.com.au/> www.coherentsoftware.com.au Developing custom web applications, desktop software and Android apps for small business. > Email: i...@coherentsoftware.com.au