cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Cocoon Fat Test
Date Mon, 10 Oct 2005 08:49:48 GMT
Stefano Mazzocchi wrote:

...

Carsten and Leszek addressed most of the other points.

> ehmmm, all right, ... but where did the standard sitemap components 
> go? [sound of stefano searching] oh, here they are
>
>  context://WEB-INF/xconf/cocoon-core-sitemap.xconf
>
> but the main sitemap doesn't link them... didn't we agree not to have 
> black magic in the sitemaps?

It is linked from cocoon.xconf, so there are no black magic, yet.

The reason for this change is that for real blocks we must declare in 
some way what components a block exposes to blocks that depend on it. So 
this means that all exposed components should be configured in one 
place. This could either be a block global component configuration, like 
cocoon.xconf or in the main sitemap. As blocks doesn't have to have a 
sitemap, they can be component only, it doesn't make that much sense to 
always require a sitemap. We decided to move the exposed sitemap 
components to a block.xconf because of that. All of this has been 
discussed on the list.

There will still not be any black magic as both the block component 
configuration and the block sitemap are refered to from block.xml. OTH 
it might be convenient to have some default locations for component 
configuration and sitemap in blocks.

At a later stage you might need to look even further for the component 
configuration. IMO components should in general be defined in the block 
that contain the implementation of them. In this way we only need to 
make interfaces exported from blocks, implementation classes can be 
internal. From this it would be more natural to consider core (src/java) 
as a block and put the configuration of the core components there 
instead on in src/webapp. This would follow the pattern from all other 
blocks.

...

> So, let's see how much I can strip it down and keep the welcome page 
> show up:
>
>  1) let's remove knopflerfish -> works

Knopflerfish is the OSGi implementation, only o.a.c.core.osgi in core 
and src/osgi-servlet depends on these. The libraries will be moved to 
lib/osgi and the o.a.c.core.osgi package will be moved to an own block, 
to make it easier to exclude the OSGi stuff from trunk while releaseing 
2.2.x. (I organized things like this from the beginning, but someone 
reorganized it).

>  2) let's remove xalan, xerces and the xml api -> works
>  3) let's remove javaflow -> works

We could also remove flowscripts to an own block. It doesn't help you, 
but would remove the fat from Rhino for those not using it. I don't 
think anything in the rest of core depends on the flowscript 
implementation anymore.

>  4) let's remove log4j -> works

Move to own block (or bundle). I think we should start to think in terms 
of library bundles (or blocks) also, i.e. blocks that just contain java 
code and/or resources, but doesn't expose components or sitemap 
functionality. We don't need to wait for start using OSGi for this. We 
could make it possible to switch on and off optional libraries as well 
as blocks.

>  5) let's remove bcel -> works
>  6) let's remove xmlbeans -> works

xmlbeans is (or at least was), only a runtime dependency for making it 
possible to use E4X in flowscripts. I should definitely become an 
optional library.

>  7) let's remove jcs -> works
>
> so, how much are we now? 4Mb the total war file. Not so bad.
>
> Where can we improve? well, cocoon.jar is about 1Mb, compressed, that 
> seems like a lot of stuff, let's see what's inside
>
>  cd dist/WEB-INF/lib
>  unzip cocoon-2.2.0.jar
>  cd org/apache/cocoon
>  du -d1 | sort -rn
>
> 3936    ./components
> 976     ./transformation
> 688     ./xml
> 664     ./core
> 632     ./environment
> 520     ./util
> 472     ./generation
> 360     ./acting
> 312     ./matching
> 272     ./sitemap
> 192     ./selection
> 192     ./bean
> 160     ./servlet
> 144     ./serialization
> 128     ./i18n
> 80      ./reading
> 72      ./caching
> 24      ./configuration
>
>  cd components
>  du -d1 | sort -rn
>
> 1040    ./treeprocessor
> 728     ./modules
> 528     ./flow
> 352     ./source
> 240     ./xpointer
> 208     ./pipeline
> 144     ./thread
> 136     ./store
> 112     ./blocks
> 88      ./sax
> 72      ./notification
> 72      ./classloader
> 56      ./crawler
> 24      ./persistence
> 24      ./fam
> 24      ./container
> 16      ./resolver
>
> hmmm, not a lot to remove, treeprocessor + flow + transformation 
> occupy pretty much all of it.

The sitemap components and some of the ordinary components. e.g. most of 
the modules, could preferably be moved to separate blocks as well.

It doesn't matter that much from "fatness" POV. But when we start with 
separate release cycles for all blocks, it will be an advantage to keep 
the "core" as small and focused as possible. That will make it obvious 
what is the core contracts, and it will also keep us diciplined about 
dependencies to core.

> With a serious diet and an improved build system, cocoon could lose 
> half of its weight and generate webapps that are much more friendly 
> for smaller sites or for inclusion in places where size is an issue.
>
> But even when size is not an issue, having smaller webapps helps in 
> making users perceive what core functionality the cocoon framework 
> gives them and what is add-on, something that we were never very good 
> at marketing.

Yes, and will also make it easier for people to start developing Cocoon, 
if we make the core lean. Now it is quite a huge amount of code to 
search in, when you try to understand the core.

/Daniel


Mime
View raw message