first steps to framework independence! vote here!

[Adam Heath-2]

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.


>

[Chris Snow-3]

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

[Adam Heath-2]

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>

[Chris Snow-3]

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

[Jacopo Cappellato-4]

On Feb 26, 2010, at 9:06 PM, Christopher Snow wrote:

> Me too, however with the current dependencies ,framework effectively depends on applications anyway.

And in fact we have to fix this.

Jacopo

>
> Jacopo Cappellato wrote:
>> I am against moving party in the framework; we can discuss if a portion of the content should be moved there.
>>
>> Jacopo
>>
>> On Feb 26, 2010, at 8:53 PM, Anil Patel wrote:
>>
>>  
>>> I rather see it differently.
>>> Framework components should core ones that compare to similar things out there. I will rather have help move out of framework instead of moving content and Party into framework.
>>>
>>> I think we should do /framework, /baseapps, /applications
>>>
>>> We can put all those core components that need data model in /baseapps.  
>>> Thanks and Regards
>>> Anil Patel
>>> HotWax Media Inc
>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>
>>> On Feb 26, 2010, at 2:36 PM, Christopher Snow wrote:
>>>
>>>    
>>>> Yes, I have looked at the patch.  I am in favor of it.  My reasoning:  "help" would be important functionality for the framework.  Help depends on some content tables which in turn depend on some party components.
>>>>
>>>> By moving entities in a similar hack, I have managed to get a standalone framework running and switch back to the full ofbiz just by changing component-load.xml
>>>>
>>>> Scott Gray wrote:
>>>>      
>>>>> Have you even looked at the patch?  It is certainly not intended to be committed.
>>>>>
>>>>> Are you in favor of the patch?  If so, could you please explain why you would like to see the party and content application components included in a framework only release?
>>>>>
>>>>> Thanks
>>>>> Scott
>>>>>
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>> On 26/02/2010, at 12:22 PM, Christopher Snow wrote:
>>>>>
>>>>>
>>>>>        
>>>>>> Bruno's question:
>>>>>>
>>>>>> "So could we please review the patch?
>>>>>> Does it make sense?"
>>>>>>
>>>>>> If there are no major objections, then I guess he will commit it?
>>>>>>
>>>>>> Scott Gray wrote:
>>>>>>
>>>>>>          
>>>>>>> What exactly are you requesting that people vote on?
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> HotWax Media
>>>>>>> http://www.hotwaxmedia.com
>>>>>>>
>>>>>>> On 26/02/2010, at 12:15 PM, Christopher Snow wrote:
>>>>>>>
>>>>>>>
>>>>>>>            
>>>>>>>> Bruno has a patch that will allow us to run ofbiz standalone - without breaking anything!
>>>>>>>>
>>>>>>>> This is a small but important step towards framework independence...
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3505
>>>>>>>>
>>>>>>>> Many thanks in advance,
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>              
>>>>>        
>>
>>  
>

[Jacopo Cappellato-4]

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

[Adam Heath-2]

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.

[Chris Snow-3]

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

[Adam Heath-2]

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

[David E. Jones-2]

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.

[Chris Snow-3]

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

[Adam Heath-2]

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.