Carsten hates me when I "just talk", so here is some action: let's measure cocoon's fat.

Follow me and type the following in your terminal

 svn co http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/ \
cocoon
 svn co http://simile.mit.edu/repository/linotype/trunk/ linotype
 export COCOON_HOME=../cocoon/
 cd linotype
 ant install
 ant run

then point your browser at http://127.0.0.1:8888/linotype/

you should see an empty linotype running.

Now, ctrl-break the above, and do

 zip -r linotype.war dist/

the resulting WAR is 12263572 bytes. How much of this is linotype?

 zip -r linotype.zip dist/linotype/

results in a 129673 bytes. Cocoon has a platform overhead of 11Mb. *compressed*

Now let's see where the things are:

 cd dist
 du -d1

returns

1152    ./linotype
144     ./resources
128     ./stylesheets
27472   ./WEB-INF
29000   .

so

 cd WEB-INF
 du -d1

returns

8       ./classes
1544    ./entities
25776   ./lib
27472   .

So, it's clear that cocoon weight is in the jars.

NOTE: the linotype build system builds cocoon from source with the most stripped-down version as Linotype does not depend on any blocks. This is the minimal 2.1.x cocoon possible right now.

Let's see the list of jars

 cd lib
 ls -AlS

(with some little hand cleaning)

2941481 jdtcore-3.0.2.jar
2730442 xalan-2.7.0.jar
1395202 cocoon-2.1.8-dev.jar
1203860 xercesImpl-2.7.1.jar
 607235 rhino1.5r4-continuations-R26.jar
 552263 commons-collections-3.1.jar
 522143 jakarta-bcel-20040329.jar
 394671 jcs-1.2.5-dev-20050313.jar
 358085 log4j-1.2.12.jar
 285104 commons-jxpath-1.2.jar
 225375 commons-httpclient-2.0.2.jar
 207723 commons-lang-2.1.jar
 194205 xml-apis-1.3.02.jar
 189284 util.concurrent-1.3.4.jar
 131458 commons-jexl-1.0.jar
 115506 excalibur-instrument-mgr-http-2.1.jar
  89145 excalibur-logger-2.1.jar
  86665 excalibur-xmlutil-2.1.jar
  83582 avalon-logkit-2.1.jar
  80572 excalibur-component-1.2.jar
  78599 excalibur-sourceresolve-2.1.jar
  65948 excalibur-naming-1.0.jar
  60047 xml-commons-resolver-1.1.jar
  59645 avalon-framework-impl-4.3.jar
  57548 excalibur-instrument-mgr-impl-2.1.jar
  47531 ehcache-1.1.jar
  42137 excalibur-store-2.1.jar
  40737 excalibur-io-1.1.jar
  38015 commons-logging-1.0.4.jar
  32112 avalon-framework-api-4.3.jar
  30117 commons-cli-1.0.jar
  28584 jakarta-regexp-1.4.jar
  27833 excalibur-pool-impl-2.1.jar
  21028 javacImpl-0.9.jar
  20640 excalibur-instrument-mgr-api-2.1.jar
  20328 excalibur-instrument-api-2.1.jar
  18329 excalibur-pool-instrumented-2.1.jar
  14728 excalibur-pool-api-2.1.jar
   8238 excalibur-i18n-1.1.jar
   3565 javacApi-0.9.jar

now, let's take a look

1) I don't use XSP nor javaflow, therefore I wouldn't need JDTcore, nor BCEL, nor javacImpl and javacAPI, a total of several Mb.

 2) I don't use the avalon instrumentation

 3) I use logkit, so I don't need log4j

4) I put the latest xalan and xerces in my app server, no need to have it here too

here is the slimmed down cocoon

1395202 cocoon-2.1.8-dev.jar
 607235 rhino1.5r4-continuations-R26.jar
 552263 commons-collections-3.1.jar
 285104 commons-jxpath-1.2.jar
 225375 commons-httpclient-2.0.2.jar
 207723 commons-lang-2.1.jar
 194205 xml-apis-1.3.02.jar
 189284 util.concurrent-1.3.4.jar
 131458 commons-jexl-1.0.jar
  89145 excalibur-logger-2.1.jar
  86665 excalibur-xmlutil-2.1.jar
  83582 avalon-logkit-2.1.jar
  80572 excalibur-component-1.2.jar
  78599 excalibur-sourceresolve-2.1.jar
  65948 excalibur-naming-1.0.jar
  60047 xml-commons-resolver-1.1.jar
  59645 avalon-framework-impl-4.3.jar
  47531 ehcache-1.1.jar
  42137 excalibur-store-2.1.jar
  40737 excalibur-io-1.1.jar
  38015 commons-logging-1.0.4.jar
  32112 avalon-framework-api-4.3.jar
  30117 commons-cli-1.0.jar
  28584 jakarta-regexp-1.4.jar
  27833 excalibur-pool-impl-2.1.jar
  18329 excalibur-pool-instrumented-2.1.jar
  14728 excalibur-pool-api-2.1.jar
   8238 excalibur-i18n-1.1.jar

which now yields a war file of 4Mb, still a lot but much better than before.

Anyway, I know some of this has been discussed at lenght on the mail list already, so I tried cocoon 2.2.x to see if things are improving, let's redo the little dance:

 svn co http://svn.apache.org/repos/asf/cocoon/trunk/ cocoon
 svn co http://simile.mit.edu/repository/linotype/trunk/ linotype
 export COCOON_HOME=../cocoon/
 cd linotype
 ant war

results in a 11516061 file, which is better than before, well, let's see if it works

 ant run

does cocoon work? [open http://127.0.0.1:8888/] yes it does.

does linotype work? [open http://127.0.0.1:8888/linotype/] nope

"Type 'jx' does not exist for 'map:transform' at", let's see the sitemap

 <map:components>

   <!-- include some additional components -->
<map:include dir="context://WEB-INF/sitemap-additions" pattern="*.xconf"/>

 </map:components>

ah, ok, cool, now the components are located somewhere else, let's see the sitemap-additions

<map:components xmlns:map="http://apache.org/cocoon/sitemap/1.0";>
  <map:generators>
<map:generator label="content" logger="sitemap.generator.mp3directory" name="mp3directory" src="org.apache.cocoon.generation.MP3DirectoryGenerator"/>
  </map:generators>

  <map:transformers>
<map:transformer logger="sitemap.transformer.jpath" name="jpath" src="org.apache.cocoon.transformation.JPathTransformer"/> <map:transformer logger="sitemap.transformer.filter" name="filter" src="org.apache.cocoon.transformation.FilterTransformer"/>
  </map:transformers>

  <map:serializers>
<map:serializer logger="sitemap.serializer.vrml" mime-type="model/vrml" name="vrml" src="org.apache.cocoon.serialization.TextSerializer"/>
  </map:serializers>

</map:components>

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?

Not sure I don't like this, reduces discoverability a great deal. But anyway, let's look for the "jx" transformer... hmmm, gone, all right, it's not that core anyway... hmmm, oh, here it is, it's the 'template' block, that wasn't there in 2.1.x, let's add this to the build system.

So, let's add -Dinclude.block.template=true when invoking ant.... run.... nope.

So, -Dinclude.block.template=true does not overwrite -Dexclude.blocks.all=true. Boy, that's lame.

The ability to exclude or include all blocks is a great one, but if individual selections don't override the default, it's a problem.

Anyway, that can be fixed.

So, here is the diff between the dist-2.1.x/WEB-INF/lib and the dist-2.2.x/WEB-INF/lib with no blocks enabled

Only in dist-2.1.x/WEB-INF/lib/: cocoon-2.1.8-dev.jar
Only in dist-2.1.x/WEB-INF/lib/: excalibur-component-1.2.jar
Only in dist-2.1.x/WEB-INF/lib/: excalibur-instrument-mgr-api-2.1.jar
Only in dist-2.1.x/WEB-INF/lib/: excalibur-instrument-mgr-http-2.1.jar
Only in dist-2.1.x/WEB-INF/lib/: excalibur-instrument-mgr-impl-2.1.jar
Only in dist-2.1.x/WEB-INF/lib/: javacApi-0.9.jar
Only in dist-2.1.x/WEB-INF/lib/: javacImpl-0.9.jar
Only in dist-2.1.x/WEB-INF/lib/: jdtcore-3.0.2.jar
Only in dist-2.1.x/WEB-INF/lib/: rhino1.5r4-continuations-R26.jar

Only in dist-2.2.x/WEB-INF/lib/: cocoon-2.2.0-dev.jar
Only in dist-2.2.x/WEB-INF/lib/: commons-javaflow-r306555.jar
Only in dist-2.2.x/WEB-INF/lib/: commons-jci-r306555.jar
Only in dist-2.2.x/WEB-INF/lib/: knopflerfish-cm_api-1.0.0.jar
Only in dist-2.2.x/WEB-INF/lib/: knopflerfish-console_all-1.0.0.jar
Only in dist-2.2.x/WEB-INF/lib/: knopflerfish-consoletty-1.0.0.jar
Only in dist-2.2.x/WEB-INF/lib/: knopflerfish-framework-1.3.3.jar
Only in dist-2.2.x/WEB-INF/lib/: knopflerfish-frameworkcommands-1.0.0.jar
Only in dist-2.2.x/WEB-INF/lib/: knopflerfish-http_all-1.1.0.jar
Only in dist-2.2.x/WEB-INF/lib/: knopflerfish-log_all-1.0.0.jar
Only in dist-2.2.x/WEB-INF/lib/: knopflerfish-logcommands-1.0.0.jar
Only in dist-2.2.x/WEB-INF/lib/: rhino-1.6R2.jar
Only in dist-2.2.x/WEB-INF/lib/: xmlbeans-1.0.3.jar

So, let's see how much I can strip it down and keep the welcome page show up:

 1) let's remove knopflerfish -> works
 2) let's remove xalan, xerces and the xml api -> works
 3) let's remove javaflow -> works
 4) let's remove log4j -> works
 5) let's remove bcel -> works
 6) let's remove xmlbeans -> works
 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.

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.

Hope this helps.

--
Stefano.

Reply via email to