what a mess! is framework independence ever going to be possible?

[Chris Snow-3]

Hi Bruno,

I think your plan makes a lot of sense and I also agree with your
spreadsheet.

We should work on the buildbot to report and enforce correct dependencies.

Cheers,

Chris

Bruno Busco wrote:

> Chris,
> I think we should at first concentrate into enforcing a components
> dependency hierarchy.
>
> This is my plan:
>
> We should select  "core" or "framework" components that are the
> minimum must be installed in order to have a running OFBiz.
>
> Then we should say: "additional component A can be installed if
> componentd B is installed also", "component C can be installed if A
> and B are installed"
>
> Having this in place will let us define some "OFBiz configurations"
> that should run properly according to the design.
>
> For instance:
> Configuration 1 -> Only the "core" components
> Configuration 2 -> Core components + component A and B
> Configuration 3 -> Core components + components A, B and C
>
> Every configuration should be automatically built by BuildBot so that
> we continuously check if unwanted dependencies are added in the
> codebase.
>
> When all this will be in place we can further work to a greater
> components separation.
> If we agree with this could we work toghether identifying the configurations?
>
> The excel sheet I have uploaded here
> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
> can be used as a tool for this.
>
> What do you think about?
>
>
> -Bruno
>
> 2010/2/7 Christopher Snow <[hidden email]>:
>  
>> Also, splitting components down into small functional areas could have the
>> benefit that if you just want WorkEffort core + parties, you wouldn't get
>> the UI contributions from WorkEffort fixed assets.
>>
>> Development would be more difficult as you would be working across multiple
>> files.  However, maybe the eclipse ofbiz IDE could provide a consolidated
>> view?
>>
>> Cheers,
>>
>> Chris
>>
>> Christopher Snow wrote:
>>    
>>> Good work Bruno!  I'm putting some thought into the dependency issues - I
>>> will provide some more feedback when I have a clearer view.  However, my
>>> current view is this:
>>> 1) Developers should be able have a standalone framework
>>> 2) Developers should be able to install components to meet certain
>>> functional areas without having to install most of the other components.
>>>  E.g. install WorkEffort as a standalone component without having to install
>>> Accounting, Party management, etc.
>>>
>>> The current implementation of ofbiz does not support (2) without breaking
>>> each component up into a number of smaller modules such as:
>>>
>>> WorkEffortCore module (has no external dependency)
>>> WorkEffortFixedAsset module (requires FixedAsset core module)
>>> WorkEffortParties module (requires Party core module)
>>>
>>> Option (2) would give maximum reuse of code and would facilitate
>>> developers in learning ofbiz as they would only need to focus on the
>>> business processes within those modules.
>>>
>>> Anyway, I'm going to play around with the above concept when I have
>>> time...
>>>
>>>
>>> Bruno Busco wrote:
>>>      
>>>> The complete url for the confluence page is:
>>>>
>>>> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
>>>>
>>>>
>>>> 2010/2/6 Bruno Busco <[hidden email]>:
>>>>
>>>>        
>>>>> I have updated the framework-only confluence page with an excel sheet
>>>>> that we could use to track the dependecies issue down.
>>>>>
>>>>> http://cwiki.apache.org/confluence/download/attachments/9373097/OFBIZ+COMP+DEPENDENCIES.xls?version=1
>>>>>
>>>>> Hope this helps. It is not yet completed.
>>>>> Please fille free to contribute to update it.
>>>>> The black "X" are dependecies that we want in the code base.
>>>>> The red "X" are dependencies that are there but should not.
>>>>>
>>>>> -Bruno
>>>>>
>>>>> 2010/2/6 Matt Warnock <[hidden email]>:
>>>>>
>>>>>          
>>>>>> On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
>>>>>>
>>>>>>            
>>>>>>> Chris,
>>>>>>>
>>>>>>> Framework independence has been a goal for quite a while. There is no
>>>>>>>  disagreement that the framework should run on its own. The
>>>>>>>  disagreements arise in what constitutes the framework.
>>>>>>>
>>>>>>> Let's assume for a moment that framework independence means running
>>>>>>> the
>>>>>>>  components in the framework folder independently from anything else
>>>>>>> in
>>>>>>>  OFBiz. Right away the problem with that idea is that visual themes
>>>>>>> are
>>>>>>>  in a separate folder outside the framework folder. Does framework
>>>>>>>  independence include the visual themes folder? That has not been
>>>>>>>  discussed. Then there are the multitude of dependencies upon the
>>>>>>>  applications folder.
>>>>>>>
>>>>>>>              
>>>>>> I'm a newbie here, but I have a lot of gray hair.  Seems like trying to
>>>>>> separate dependencies by folder or subject matter is an exercise doomed
>>>>>> to failure.
>>>>>>
>>>>>> TCP/IP has taken over the world because it has a clear model based on
>>>>>> separate layers (the 7-layer OSI model).  Changes on one level (like
>>>>>> 10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
>>>>>> rest.  Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
>>>>>> means to map IP addresses to hostnames at the application layer--
>>>>>> TCP/IP
>>>>>> doesn't care.
>>>>>>
>>>>>>
>>>>>>            
>>>>>>> From my perspective, achieving this objective will require a two
>>>>>>>  pronged approach: 1) Identify the framework dependencies on outside
>>>>>>>  components, and 2) avoid introducing new framework dependencies on
>>>>>>>  outside components.
>>>>>>>
>>>>>>>              
>>>>>> This assumes the "framework" is the lowest level.  If the framework
>>>>>> depends on outside components, then the hierarchy has been upset, and
>>>>>> spaghetti dependencies are the inevitable result.  Dependencies HAVE to
>>>>>> be unidirectional, or you never get out of the maze.  IMHO, the biggest
>>>>>> problem with MVC is that it has never seemed to me that the layers are
>>>>>> very well defined.  Everything seems pretty interdependent, and you
>>>>>> quickly get into a rock/paper/scissors kind of analysis, as you
>>>>>> describe.
>>>>>>
>>>>>> Is there a comprehensible map of the layers in OFBiz?  All I have seen
>>>>>> is very detailed charts that seem to obfuscate, rather than clarify,
>>>>>> the
>>>>>> relationships of the various modules.  But I'm sure I have not seen
>>>>>> everything.  Is there a 30,000-foot overview of the software levels?
>>>>>>
>>>>>>
>>>>>>            
>>>>>>> The first prong can be accomplished through contributions from people
>>>>>>>  like you - find the dependencies and create patches to fix them.
>>>>>>>
>>>>>>> The responsibility of the second prong is up to the committers. We
>>>>>>> need
>>>>>>>  to be more vigilant to guard against introducing new dependencies.
>>>>>>>
>>>>>>>              
>>>>>> Which requires a clear model of what layer the code under consideration
>>>>>> belongs to, and what are the well-defined layers below it that can be
>>>>>> dependencies.
>>>>>>
>>>>>>            
>>>>>>> Personally I believe it will be possible, BUT it won't be easy. The
>>>>>>>  obstacles to overcome will be getting people to contribute to the
>>>>>>>  effort, and getting committers to avoid introducing new dependencies.
>>>>>>>
>>>>>>>              
>>>>>> Again, I think we need to reduce the learning curve by providing clear
>>>>>> maps.  You shouldn't need to know everything to be able to contribute
>>>>>> meaningful and error-free code.
>>>>>>
>>>>>>            
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> --- On Fri, 2/5/10, Christopher Snow <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>> From: Christopher Snow <[hidden email]>
>>>>>>>> Subject: what a mess! is framework independence ever going to be
>>>>>>>> possible?
>>>>>>>> To: [hidden email]
>>>>>>>> Date: Friday, February 5, 2010, 10:58 PM
>>>>>>>> I'm back to the process of working
>>>>>>>> out how to get a standalone framework running based on
>>>>>>>> trunk, but I have found that the dependencies have got out
>>>>>>>> of hand (if I've understood the code right):
>>>>>>>>
>>>>>>>> Framework  depends on Themes
>>>>>>>> Themes depends on Content
>>>>>>>> Content depends on Party
>>>>>>>>
>>>>>>>> The questions I'm starting to ask myself are:
>>>>>>>>
>>>>>>>> "Is is ever going to be possible to have framework
>>>>>>>> independence in trunk?  Independence in 9.04 is
>>>>>>>> relatively trivial (rewrite security screens) perhaps the
>>>>>>>> most sensible thing would be to do a fork of 9.04 and then
>>>>>>>> back port all framework related commits from trunk? "
>>>>>>>>
>>>>>>>> Any ideas anyone?
>>>>>>>>
>>>>>>>> Many thanks,
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>>>              
>>>>>> --
>>>>>> Matt Warnock <[hidden email]>
>>>>>> RidgeCrest Herbals, Inc.
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>