cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@apache.org>
Subject Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Date Sat, 13 Apr 2002 16:37:08 GMT
On Sat, 13 Apr 2002 14:06:53 +0200 (CEST), giacomo <giacomo@apache.org> 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 <ovidiu@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message