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

[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!

[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!

[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!

[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).

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

[Bruno Busco <br...@gmail.com>]

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!

[Christopher Snow <sn...@snowconsulting.co.uk>]

Please excuse my ignorance...

If the ofbiz src tree was split up into new svn projects (e.g. entity 
engine, service engine, etc) , would ant be able to easily manage the 
dependencies between each project? 

If maven doesn't do the job of managing dependencies very well, what 
about ivy?

Many thanks,

Chris


Adam Heath wrote:
> Christopher Snow wrote:
>   
>> Hi Adam, do you know of any tools available that meet these requirements?
>>     
>
> Um, I may be going out on a limb here, but ant?
>
>   
>> Adam Heath wrote:
>>     
>>> Christopher Snow wrote:
>>>
>>>       
>>>> Hi Adam,
>>>>
>>>> What would be your preferred tool for managing the builds if we made
>>>> ofbiz more modular?
>>>>     
>>>>         
>>> Must be stand-alone.  Can't depend on anything from the network.
>>>
>>> Network resources may not be available in all cases.  Plus, network
>>> resources can become stale, and go away, even if the network is
>>> available.
>>>
>>> Can't require system libraries.  Can make use of system libraries, but
>>> needs to be able to be completely embedded, if necessary.
>>>
>>> This is to reduce the requirement of installing a bunch of extra stuff
>>> outside of the project being manipulated.
>>>
>>> Having a build definition file, that is then used to generate the
>>> actual build script(s), which are then cached, is frowned upon.
>>>
>>> Such systems are notorious for not updating the generated files when
>>> the generating parts have been updated.  This is even more of a
>>> problem when only some dependent parts are updated, and you get
>>> mismatched generated parts, that then have funky weird issues.
>>>
>>> Those are my main three points that I would like to see addressed in
>>> any kind of build automation framework.
>>>   
>>>       
>
>   

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

[Adam Heath <do...@brainfood.com>]

Christopher Snow wrote:
> Hi Adam, do you know of any tools available that meet these requirements?

Um, I may be going out on a limb here, but ant?

> 
> Adam Heath wrote:
>> Christopher Snow wrote:
>> 
>>> Hi Adam,
>>>
>>> What would be your preferred tool for managing the builds if we made
>>> ofbiz more modular?
>>>     
>>
>> Must be stand-alone.  Can't depend on anything from the network.
>>
>> Network resources may not be available in all cases.  Plus, network
>> resources can become stale, and go away, even if the network is
>> available.
>>
>> Can't require system libraries.  Can make use of system libraries, but
>> needs to be able to be completely embedded, if necessary.
>>
>> This is to reduce the requirement of installing a bunch of extra stuff
>> outside of the project being manipulated.
>>
>> Having a build definition file, that is then used to generate the
>> actual build script(s), which are then cached, is frowned upon.
>>
>> Such systems are notorious for not updating the generated files when
>> the generating parts have been updated.  This is even more of a
>> problem when only some dependent parts are updated, and you get
>> mismatched generated parts, that then have funky weird issues.
>>
>> Those are my main three points that I would like to see addressed in
>> any kind of build automation framework.
>>   
> 

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

Hi Adam, do you know of any tools available that meet these requirements?

Adam Heath wrote:
> Christopher Snow wrote:
>   
>> Hi Adam,
>>
>> What would be your preferred tool for managing the builds if we made
>> ofbiz more modular?
>>     
>
> Must be stand-alone.  Can't depend on anything from the network.
>
> Network resources may not be available in all cases.  Plus, network
> resources can become stale, and go away, even if the network is available.
>
> Can't require system libraries.  Can make use of system libraries, but
> needs to be able to be completely embedded, if necessary.
>
> This is to reduce the requirement of installing a bunch of extra stuff
> outside of the project being manipulated.
>
> Having a build definition file, that is then used to generate the
> actual build script(s), which are then cached, is frowned upon.
>
> Such systems are notorious for not updating the generated files when
> the generating parts have been updated.  This is even more of a
> problem when only some dependent parts are updated, and you get
> mismatched generated parts, that then have funky weird issues.
>
> Those are my main three points that I would like to see addressed in
> any kind of build automation framework.
>   

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

[Adam Heath <do...@brainfood.com>]

David E Jones wrote:
> Thanks for this Adam. These are great points maven versus ant.

It may be possible to do what I want with maven.  But the fact that in
*all* cases where I have had the horror of seeing maven used by a
project, they have *all* been network based, required maven installed
in the system, and then installed their built files into $HOME
somewhere, tells me that it's not possible.

And/or no one really understands how to *use* maven, and they just
copy things from a select few who exist on high, that actually do.
This is not a tool I wish to use.  It tells me it is too hard to
actually understand and extend.

The best tools are those that get used for something the original
authors never intended.

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

[David E Jones <de...@me.com>]

Thanks for this Adam. These are great points maven versus ant.

-David


On Feb 27, 2010, at 9:43 AM, Adam Heath wrote:

> Christopher Snow wrote:
>> Hi Adam,
>> 
>> What would be your preferred tool for managing the builds if we made
>> ofbiz more modular?
> 
> Must be stand-alone.  Can't depend on anything from the network.
> 
> Network resources may not be available in all cases.  Plus, network
> resources can become stale, and go away, even if the network is available.
> 
> Can't require system libraries.  Can make use of system libraries, but
> needs to be able to be completely embedded, if necessary.
> 
> This is to reduce the requirement of installing a bunch of extra stuff
> outside of the project being manipulated.
> 
> Having a build definition file, that is then used to generate the
> actual build script(s), which are then cached, is frowned upon.
> 
> Such systems are notorious for not updating the generated files when
> the generating parts have been updated.  This is even more of a
> problem when only some dependent parts are updated, and you get
> mismatched generated parts, that then have funky weird issues.
> 
> Those are my main three points that I would like to see addressed in
> any kind of build automation framework.

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

[Adam Heath <do...@brainfood.com>]

Christopher Snow wrote:
> Hi Adam,
> 
> What would be your preferred tool for managing the builds if we made
> ofbiz more modular?

Must be stand-alone.  Can't depend on anything from the network.

Network resources may not be available in all cases.  Plus, network
resources can become stale, and go away, even if the network is available.

Can't require system libraries.  Can make use of system libraries, but
needs to be able to be completely embedded, if necessary.

This is to reduce the requirement of installing a bunch of extra stuff
outside of the project being manipulated.

Having a build definition file, that is then used to generate the
actual build script(s), which are then cached, is frowned upon.

Such systems are notorious for not updating the generated files when
the generating parts have been updated.  This is even more of a
problem when only some dependent parts are updated, and you get
mismatched generated parts, that then have funky weird issues.

Those are my main three points that I would like to see addressed in
any kind of build automation framework.

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

Hi Adam,

What would be your preferred tool for managing the builds if we made 
ofbiz more modular?

Many thanks,

Chris

Adam Heath wrote:
> Christopher Snow wrote:
>   
>> Hi Adam,
>>
>> I too would like to see a more modular ofbiz (e.g. maven + osgi), but
>> that is a big step.  For example, it would be great if people wanting to
>> use just the entity engine could just download the entity engine jars
>> and be up and running.
>>     
>
> Ew!  You said the m-word!
>
> maven is like automake, <forrest-gump>and that's all I have to say
> about that.</forrest-gump>
>   

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

[Adam Heath <do...@brainfood.com>]

Christopher Snow wrote:
> Hi Adam,
> 
> I too would like to see a more modular ofbiz (e.g. maven + osgi), but
> that is a big step.  For example, it would be great if people wanting to
> use just the entity engine could just download the entity engine jars
> and be up and running.

Ew!  You said the m-word!

maven is like automake, <forrest-gump>and that's all I have to say
about that.</forrest-gump>

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

Hi Adam,

I too would like to see a more modular ofbiz (e.g. maven + osgi), but 
that is a big step.  For example, it would be great if people wanting to 
use just the entity engine could just download the entity engine jars 
and be up and running.

However, what Bruno and I are proposing is just a first small step 
towards that.  Much more needs to be done after this first step.

Many thanks,

Chris

Adam Heath wrote:
> 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.
>