On Sat, 13 Apr 2002 14:06:53 +0200 (CEST), giacomo <[EMAIL PROTECTED]> wrote:
> > > I only think that if we do this for 2.1 it will take forever for us to > > > reach a final release... this is the reason why I was considering > > > componentization refactoring to happen for 2.2 at least. > > > > > > What do you think? > > > > > > > I'm not saying we should go through and implement the COcoon > > Application COmponentarchitecture now. I am saying we need to quell any > > further unnecessary componentization as we are now busting at the seams. > > > > What I would like to see is that all _optional_ components be broken out > > into little "mini" projects with their associated classes all in one > > place. Kind of like what we recently did with Excalibur. In fact, when > > we finally get the bugs worked out of the dependancy system, I'm sure > > you can adopt the recursive dependancy build system in Excalibur for the > > Cocoon components. > > Not even the optional component. I can see that we split up the source > using the following approach (as a first step): > > core/ > environment/ > servlet/ > cli/ > components/ > ... > > 1) Break out everything that make the o.a.c.Cocoon class compile into > the core package. > > 2) Isolate the different environments into a sub tree. I mean > separating the servlet environment from the cli environment can reduce > the size of a deployed Cocoon for the intended use. So Avalon and other > projects which build their site and docs using Cocoon don't need a > servlet environment. Those which use Cocoon in a servlet env don't need > the cli stuff. > > 3) Start separating out some very basic sitemap component > implementation (like the Reader, FileGenerator, XMLSerializer) to > finally enable testing the stuff from 1) and 2). > > 4) Start separating other components. One way could be to separate > components based on the optional jar list (FOP components, DELI > components, Lucene components, Velocity components, etc.) > > I'm sure the steps above will be repeated in cycles to beak out the > right stuff but could lead to clearly (or at least better) separate > things. I'm glad everybody is on the same page about splitting Cocoon in smaller components. The current approach is far from scalable, and is very difficult to extend. I've done a similar analysis in the "splitting Cocoon" thread few days ago: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101855989717239&w=2 > > Another thing that it allows us to do is start considering the > > role of the sitemap in regards to dynamic loading of jars. We > > currently let the servlet engine load all jars associated with a > > webapp. If we want true pluggability, we need to let subsitemaps > > load their own set of jars so that we can have true component > > isolation. Also, so that when we come up with the formal Cocoon > > Application ComponenT Infrastructure (CACTI?) or whatever we call > > it, we also have the component loading infrastructure in place. > > Exactly, this has beed discussed by Stefano and me when he was here > at my place two weeks ago. I think that the Cocoon core must be able > to build a ClassLoader instatiated with the set of jars described in > the yet to be defined Cocoon Block Descriptor Language (CBDL) for > each Cocoon Block. There is the need to have a ComponentManager to > be build up with the components mentioned in the Cocoon Block > Description (CBD) for private components for each Cocoon Block as > well. > > For the exported components of the deployed Cocoon Blocks I see two > ways of making them available to the other Cocoon Blocks: > > 1) Have a root CM populated with the exported components from each > Cocoon Block. > > 2) Populate the CM for each Cocoon Block with components the Cocoon > Block in question depoends on. > > In 1) we choose a lazy way of collection all available components into > one CM. The approach in 2) makes access to components possible exactly > as mentioned in the CBD for the block. How do we make sure that blocks that need conflicting versions of the same block still work fine? If a block populates the root CM with its dependency classes, the next block coming along will mess up with them. Perhaps a tree like structure for CM's will help here, where the root CM is protected from writing to. Regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
