ofbiz framework component in trunk is misleading?

[Jim S]

... As it does contains the applications component as well. 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?

Thanks in advance.

--
Thanks,
Jim

[brajeshpatel]

Dear Jim,

following url will give you component wise code

http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/

try to do svn checkout it will work, 

following component structure you will get

On Mon, Feb 19, 2018 at 4:02 AM, Jim S <[hidden email]> wrote:

... As it does contains the applications component as well. 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?

Thanks in advance.

--
Thanks,
Jim

--

[taher]

Hi Jim,

I don't quite understand your question. What do you mean by saying
framework only component and how did you get this impression? Are you
referring to the directory structure? What is bothering / confusing you
about it?

On Feb 19, 2018 1:32 AM, "Jim S" <[hidden email]> wrote:

... As it does contains the applications component as well. 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?

Thanks in advance.

--
Thanks,
Jim

[Paul Foxworthy]

Hi Taher,

I think the point is the name "framework" implies a supporting library for
an application, not an application per se.

We more or less have it right in the folder structure for the code - there
are folders called applications and framework. But the name of the project
on Subversion and GitHub does imply OFBiz is a framework.

The confusion didn't occur to me at the time we split out the plugins,
because I'm too close to it and already know what OFBiz is. But it is a
valid point. It may be too late to change, but should we consider "OFBiz
Core" or some other name?

Cheers

Paul Foxworthy

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[Paul Foxworthy]

On 19 February 2018 at 09:32, Jim S <[hidden email]> 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: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[taher]

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 <[hidden email]> wrote:

> On 19 February 2018 at 09:32, Jim S <[hidden email]> 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: [phone]
> Web: http://www.coherentsoftware.com.au/
> Email: [hidden email]

[Timothy Boyden]

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 <[hidden email]>
Sent: Monday, February 19, 2018 11:48 AM
To: [hidden email]
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 <[hidden email]> wrote:

> On 19 February 2018 at 09:32, Jim S <[hidden email]> 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: [phone]
> 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: [hidden email]

[Jim S]

Thanks all for your thoughts.

Tim, rightly said the core strength of OFBiz has been the built-in ERP and
universal database along with the framework (services, entity engine,
security, logging etc.). I believe since most of the contributors, service
providers, end users etc. use OFBiz as a built-in ERP product, the focus
may have never been on isolating the framework in its own installable
component. I would not say it is not possible today but having a framework
only component would open the gates to develop other business application
on top of OFBiz similar to what Spring and other framework provides. I see
the segregation of the specialpupose/plugin as a right step in the
direction of completely isolating the components.

Taher, If you and other agree with the name is actually misleading for new
users and others who cannot keep up with the latest developments, I think
adding a note in the documentation would certainly help.

--
Thanks,
Jim

[taher]

Hi Jim and everyone,

As a matter of fact, in the README.md there is a section called
"Repository and directory structure" that describes the changes that
were made. Maybe we can improve it a bit, but we have at least
something as a reference for users to learn from.

On Mon, Feb 19, 2018 at 10:16 PM, Jim S <[hidden email]> wrote:

> Thanks all for your thoughts.
>
> Tim, rightly said the core strength of OFBiz has been the built-in ERP and
> universal database along with the framework (services, entity engine,
> security, logging etc.). I believe since most of the contributors, service
> providers, end users etc. use OFBiz as a built-in ERP product, the focus
> may have never been on isolating the framework in its own installable
> component. I would not say it is not possible today but having a framework
> only component would open the gates to develop other business application
> on top of OFBiz similar to what Spring and other framework provides. I see
> the segregation of the specialpupose/plugin as a right step in the
> direction of completely isolating the components.
>
> Taher, If you and other agree with the name is actually misleading for new
> users and others who cannot keep up with the latest developments, I think
> adding a note in the documentation would certainly help.
>
> --
> Thanks,
> Jim