ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Busco <bruno.bu...@gmail.com>
Subject Re: Moving securityext to the framework
Date Sun, 03 Jan 2010 09:53:25 GMT
When I sayd "at least me" I should have said "To implement the
framework-only distribution end-user requirements here
We should agree or change what is written there and then work to implement it.

The framework-only work should of course generate two workproducts:
- A standalone framework implementing the requirements
- A set of additional components, each with its declared dependencies,
that can be plugged in the framework-only installation.

For my next project all I would like to do is to select the newly
needed components and plug them in the framework-only.

The sets of components framework+party+content+commonext should give
us a basic configuration that, from the user POV should be similar to
a CMS system but powered by OFBiz.
This CMS configuration, IMO, should have the greatest number of
potential users and, for this reason, should receive a greater
contribution from a greater community.

This configuration is also what we would need to run the OFBiz web
site itself (if we are still interested in getting this up and

Of course, as you say, there are some things in the selected
components (framework, party, content, commonext) that are not
required. These parts are, for sure, the ones that do not let the
database to be even created because depends on other components. There
are entities that should be moved away from party as the complete
org.ofbiz.party.agreement and org.ofbiz.party.need sets, some other
that should be extended in other components.

So coming to your question: "what should we change in how we're doing things?"
May be nothing. Just discuss/agree on the requirements for the
framework-only and then start working on a branch.


2010/1/2 David E Jones <dejc@me.com>:
> On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote:
>>> One major question is whether framework, on its own, should even be
>>> runnable as an application. In my opinion, it is a library, not an app
>>> and doesn't need to be operational on its own.
>> The more we discuss about this the more I get convinced that what we
>> (or at least me) intend for framework-only distribution should be
>> better named "OFBiz-core".
>> The OFBiz-core could consist of framework + party + content + commonext.
>> A distribution with these components set up is somewhat similar to
>> what I mean for a framework where developer can start building its
>> office automation application without the necessity to disable
>> anything but having all the power of the framework and the "core"
>> applications.
> Your "at least me" comment is right on. Consider that what you want, at least right now,
is framework + party + content + commonext. Do you think that will be the same for your next
project? Do you think that this is the same for a majority of current and prospective users
of OFBiz?
> I'd be willing to bet a good deal of money that this level of granularity is not adequate
to describe what you actually need/want, and that within each of the parts you listed (framework,
party, content, commonext) there are dozens or hundreds of more specific things that you either
want or don't want.
> Now consider that with many thousands of such things that will be wanted or not wanted,
there are an incredible number of combinations of these things. Each combination is a potential
"core" packaging of OFBiz.
> So, the question is what will be of most use to the largest number of users? That question
a good guiding thought, and because of the community nature of this project it will of course
be tempered by what contributors (committers or not) actually decide is important to them.
> Based on that, what should we change in how we're doing things?
> -David

View raw message