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: user@ofbiz.apache.org
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

Reply via email to