Hi BJ, sorry but what I meant for "configuration" 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 <bjf...@free-man.net>: > 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 <sno...@snowconsulting.co.uk>: >>> 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 <bruno.bu...@gmail.com>: >>>>> >>>>>> 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 <mwarn...@ridgecrestherbals.com>: >>>>>> >>>>>>> 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 <sno...@snowconsulting.co.uk> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> From: Christopher Snow <sno...@snowconsulting.co.uk> >>>>>>>>> Subject: what a mess! is framework independence ever going to be >>>>>>>>> possible? >>>>>>>>> To: user@ofbiz.apache.org >>>>>>>>> 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 <mwarn...@ridgecrestherbals.com> >>>>>>> RidgeCrest Herbals, Inc. >>>>>>> >>>>>>> >>>>>>> >>> >> > >
