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