On Sab, 16 de Abril de 2005, 13:15, Daniel Fagerstrom dijo: > Torsten Curdt wrote: >>>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.
+1 I thought this is the target in 2.2. ;-) > 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. > >> 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 > 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. > >> 699081 9 Mar 22:25 rhino-1.6R1.jar > It 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.jar > Used 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.jar > Used in JCSDefaultStore, do we need such a sofisticated store in core > couldn't that be optional? +1 It is no more part of the cocoon core, it is an optional one. >> 352291 9 Mar 22:25 log4j-1.2.9.jar > Used in CoreUtil and Log4JConfigurator > >> 285104 9 Mar 22:25 commons-jxpath-1.2.jar > Used 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. AFAIK, this is part of Java 1.5. >> 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. We use log4j then it is needed at all??? Perhaps we can move it to optional too. Is posible? >> 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 Best Regards, Antonio Gallardo
