Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42615633.9070304@nada.kth.se>
Date: Sat, 16 Apr 2005 20:15:15 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] what about cocoon on a diet?
References: <42612A0C.1060607@apache.org> <42612FC0.9020502@apache.org>
In-Reply-To: <42612FC0.9020502@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

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?

>   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.

>   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