for that use the datamodel books and look at the data in each application and see if it uses data from other applications. if it does there is a dependency.
Bruno Busco sent the following on 2/7/2010 1:57 AM: > Hi BJ, > sorry but what I meant for "configfoation" is different from what I > see you addressed in these jiras. > For configuration I mean a defined set of components that are supposed > to work without any other component in the installation. > > -Bruno > > > 2010/2/7 BJ Freeman <[email protected]>: >> both Hans and I have been working on configuration >> Hans is in the trunk. I have yet to get mine put in the Jira. >> https://issues.apache.org/jira/browse/OFBIZ-636 >> https://issues.apache.org/jira/browse/OFBIZ-635 >> >> Bruno Busco sent the following on 2/7/2010 12:38 AM: >>> 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 <[email protected]>: >>>> 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 <[email protected]>: >>>>>> >>>>>>> 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 <[email protected]>: >>>>>>> >>>>>>>> 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 <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> From: Christopher Snow <[email protected]> >>>>>>>>>> Subject: what a mess! is framework independence ever going to be >>>>>>>>>> possible? >>>>>>>>>> To: [email protected] >>>>>>>>>> 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 <[email protected]> >>>>>>>> RidgeCrest Herbals, Inc. >>>>>>>> >>>>>>>> >>>>>>>> >> >
