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 :-(
I support making Cocoon core small. Not that I need it to be small right now, even if that could change, but because we need to get Cocoon as modular as possible to fight entropy and keep it managable. I wold like to see a Cocoon core that consist of component manager, tree processor, a minimal environment, block manager (when we get there), basic APIs and not much more.
I would suggest that we create a block (current not real ;) ) called "base" or something similar and moves all components that not must be in core to base. All sitemap components and most other components should be moved IMO.
We could possibly split core in api and impl to make things even clearer. But it is probably to much work.
Base could later be splitted in smaller parts if we wanted to modularize further.
Could be moved to an own block or removed. We added it to support the use of E4X that is part of the new Rhino, http://www.mozilla.org/rhino/download.html. Its pretty cool stuff, but we don't need to have it in core.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.jarIt is part of core of ideological reasons. We could move JS flow to an own block. JXTG depends on Rhino as noted in another thread, but hopefully we can get rid of that dependency and furthermore JXTG will not be part of core anymore if no one vote against it.
552263 9 Mar 22:25 commons-collections-3.1.jarUsed in XMLFileModule which should go to "base" IMO and JCSDefaultStore to get an IteratorEnumeration
394671 14 Mar 19:56 jcs-1.2.5-dev-20050313.jarUsed in JCSDefaultStore, do we need such a sofisticated store in core couldn't that be optional?
352291 9 Mar 22:25 log4j-1.2.9.jar
Used in CoreUtil and Log4JConfigurator
285104 9 Mar 22:25 commons-jxpath-1.2.jarUsed in a couple of places, direct uses should IMO be replaced with the exprsion language interface that I developed as part of Template.
225375 9 Mar 22:25 commons-httpclient-2.0.2.jar
Could not find any direct use, needed for some other jar maybe?
216049 9 Mar 22:25 commons-lang-2.0-20041007T2305.jar
Used in many places.
189284 9 Mar 22:25 util.concurrent-1.3.4.jar
Many places in components thread.
131458 9 Mar 22:25 commons-jexl-1.0.jar
Used in JXTG, see comment for JXPath.
91717 9 Mar 22:25 logkit-1.2.2.jar
Used in many places.
80054 9 Mar 22:25 servlet-2_3.jar
Shoul in principle be movable to an HTTPEnvironment block.
The rest seem to be necessary or small.
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?
There seem to be a lot that can be done in modularizing Cocoon.
/Daniel
