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
