> So, my question for the group is: how can we make the cocoon core even > smaller? > > It would suck pretty bad if our group had to rewrite parts of cocoon > just because of the many dependencies and size :-(
Just looking at the current libs in trunk I think
there is quite some potential for shrinking.
1903579 9 Mar 22:25 xmlbeans-1.0.3.jar
699081 9 Mar 22:25 rhino-1.6R1.jar
552263 9 Mar 22:25 commons-collections-3.1.jar
394671 14 Mar 19:56 jcs-1.2.5-dev-20050313.jar
352291 9 Mar 22:25 log4j-1.2.9.jar
285104 9 Mar 22:25 commons-jxpath-1.2.jar
225375 9 Mar 22:25 commons-httpclient-2.0.2.jar
216049 9 Mar 22:25 commons-lang-2.0-20041007T2305.jar
189284 9 Mar 22:25 util.concurrent-1.3.4.jar
131458 9 Mar 22:25 commons-jexl-1.0.jar
91717 9 Mar 22:25 logkit-1.2.2.jar
80054 9 Mar 22:25 servlet-2_3.jar
77569 9 Mar 22:25 excalibur-xmlutil-1.0.jar
76725 9 Mar 22:25 excalibur-logger-1.1.jar
67183 9 Mar 22:25 excalibur-sourceresolve-1.1.jar
65948 9 Mar 22:25 excalibur-naming-1.0.jar
60047 9 Mar 22:25 xml-commons-resolver-1.1.jar
50233 9 Mar 22:25 avalon-framework-impl-4.1.5.jar
47531 9 Mar 22:25 ehcache-1.1.jar
40737 9 Mar 22:25 excalibur-io-1.1.jar
39050 27 Mar 16:01 commons-jci-r159148.jar
38015 9 Mar 22:25 commons-logging-1.0.4.jar
34781 9 Mar 22:25 excalibur-store-1.0.jar
30117 9 Mar 22:25 commons-cli-1.0.jar
28079 9 Mar 22:25 avalon-framework-api-4.1.5.jar
24480 15 Apr 21:37 excalibur-pool-impl-2.0.0.jar
17669 9 Mar 22:25 excalibur-instrument-1.0.jar
14822 15 Apr 21:37 excalibur-pool-instrumented-2.0.0.jar
11246 15 Apr 21:37 excalibur-pool-api-2.0.0.jar
8238 9 Mar 22:25 excalibur-i18n-1.1.jar
And in theory ProGuard should do that just fine
...but I fear the point is that ProGuard cannot
really find the stuff that you don't want or need
unless we split the core further down into smaller
chunks.
So you suggest to further modularize the core?
cheers
--
Torsten
signature.asc
Description: OpenPGP digital signature
