You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Bruno Busco <br...@gmail.com> on 2010/02/26 22:47:48 UTC

Re: What is ofbiz? was Re: first steps to framework independence! vote here!

This is what I am also trying to do.
Just have the possibility to *remove* all the applications but party
and content from an OFBiz installation and have it working.
Please stop thinking about moving things in or out of the framework.

The framework, if you like how it is right now, can stay there but
please let us create the possibility to remove applications according
to their declared dependency tree.

-Bruno

2010/2/26 Adam Heath <do...@brainfood.com>:
> You haven't gone far enough.
>
> Stop thinking about just what you want.  Or just what Bruno wants.  Or
>  what the guy from Timbuktu wants.
>
> Think about what we all want.
>
> Namely, the ability to pick and choose the parts of ofbiz that we want
> to make use of.
>
> Arbitrary assignments of components into parts is the wrong approach.
>  Add features to lower-level components that can be extended by
> higher-level components.  Add dependency references between components
> as required.
>

Re: What is ofbiz? was Re: first steps to framework independence! vote here!

Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Feb 26, 2010, at 10:47 PM, Bruno Busco wrote:

> This is what I am also trying to do.
> Just have the possibility to *remove* all the applications but party
> and content from an OFBiz installation and have it working.

I think this has to be done into two separate and independent steps:
1) framework (without party and content) independence
2) content and party independence from the other applications

I think they are very different goals and I am sure that there are different people interested in one, two or both.
For example, I am interested in #1 and I am less interested (I am not saying it is a bad thing, but not worth of the effort considering how I am using OFBiz) in #2.

Jacopo

> Please stop thinking about moving things in or out of the framework.
> 
> The framework, if you like how it is right now, can stay there but
> please let us create the possibility to remove applications according
> to their declared dependency tree.
> 
> -Bruno
> 
> 2010/2/26 Adam Heath <do...@brainfood.com>:
>> You haven't gone far enough.
>> 
>> Stop thinking about just what you want.  Or just what Bruno wants.  Or
>>  what the guy from Timbuktu wants.
>> 
>> Think about what we all want.
>> 
>> Namely, the ability to pick and choose the parts of ofbiz that we want
>> to make use of.
>> 
>> Arbitrary assignments of components into parts is the wrong approach.
>>  Add features to lower-level components that can be extended by
>> higher-level components.  Add dependency references between components
>> as required.
>> 


Re: What is ofbiz? was Re: first steps to framework independence! vote here!

Posted by Adam Heath <do...@brainfood.com>.
Adam Heath wrote:
> Bruno Busco wrote:
>> This is what I am also trying to do.
>> Just have the possibility to *remove* all the applications but party
>> and content from an OFBiz installation and have it working.
>> Please stop thinking about moving things in or out of the framework.
>>
>> The framework, if you like how it is right now, can stay there but
>> please let us create the possibility to remove applications according
>> to their declared dependency tree.
> 
> Here are more details to how I'd like to see this done.
> 
> ==
> ./startofbiz.sh run
> ./startofbiz.sh tests
> ./startofbiz.sh install
> ==
> 
> Instead of having hard-coded properties files in the start component,
> which then reference hard-coded foo-containers.xml, each component
> that is installed should be allowed to 'register' what it would like
> each run-target to do.
> 
> This would make switching between catalina and jetty simple, by just
> swapping the components, with no editting of anything else.
> 
> It would make writing an asterisk component simpler, as it has it's
> own container that has to be run, but modifying the global configs is
> difficult.
> 
> It would allow for adding new startup targets, ones that ofbiz hasn't
> thought of yet(would allow for some types of tests to be run, that
> don't require entity/service/webapps to be configured, but do require
> everything on the classpath).

ContactMech, TelecomNumber, PostalAddress are more generic than just
for party.  They should be in a shareable component.  orders have a
shipping destination, which has nothing to do with a party.  Same for
facilities.

Party is more generic than the party component.  Person/PartyGroup
should be higher-level, while Party be lower-level.

Our components are to large, imho.


> 


Re: What is ofbiz? was Re: first steps to framework independence! vote here!

Posted by Adam Heath <do...@brainfood.com>.
Bruno Busco wrote:
> This is what I am also trying to do.
> Just have the possibility to *remove* all the applications but party
> and content from an OFBiz installation and have it working.
> Please stop thinking about moving things in or out of the framework.
> 
> The framework, if you like how it is right now, can stay there but
> please let us create the possibility to remove applications according
> to their declared dependency tree.

Here are more details to how I'd like to see this done.

==
./startofbiz.sh run
./startofbiz.sh tests
./startofbiz.sh install
==

Instead of having hard-coded properties files in the start component,
which then reference hard-coded foo-containers.xml, each component
that is installed should be allowed to 'register' what it would like
each run-target to do.

This would make switching between catalina and jetty simple, by just
swapping the components, with no editting of anything else.

It would make writing an asterisk component simpler, as it has it's
own container that has to be run, but modifying the global configs is
difficult.

It would allow for adding new startup targets, ones that ofbiz hasn't
thought of yet(would allow for some types of tests to be run, that
don't require entity/service/webapps to be configured, but do require
everything on the classpath).