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: <42551A75.6020506@nada.kth.se>
Date: Thu, 07 Apr 2005 13:33:09 +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: The value of src/core (or lack thereof)
References: <42550DCB.7040200@apache.org>
In-Reply-To: <42550DCB.7040200@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sylvain Wallez wrote:

> Hi all,
>
> The src/core directory was initially created to clearly separate the 
> development of ECM++ and ensure it had no dependencies of other parts 
> of Cocoon.
>
> All went well until we added some fancy features like includes, 
> variable expansion, etc, which led an increasing number of classes to 
> move from src/java to src/core. Having e.g. classes in the 
> o.a.c.environment packages spread over the two directories is somewhat 
> confusing.
>
> What this shows is that although the Cocoon engine has very few 
> dependencies on ECM++, ECM++ has an increasing number of dependencies 
> on the Cocoon engine.
>
> Since we recently added support for other component containers 
> _inside_ ECM++, what is now the real value of src/core? Not much IMO.
>
> So I propose to remove src/core and move all its content to src/java.
>
> WDYT?

I think that I agree :) I have also thought about the separation between 
src/core and src/java lately as it have becoming increasingly unclear to 
me where the border should be with the recent aditions to core.

IMO there would be a value in the separation, if we put what is needed 
for executing the sitemap engine and basic apis in core and nothing 
else. So that the core is the basic execution and component management 
mechanism for Cocoon. But I would assume that it would be quite a lot of 
work to get the border right and we have more important things to do, so 
for the moment it is probably better to merge the trees.

I would assume that we will need to do some refactorings of the "core" 
parts of Cocoon when we start to develop the block manager, to get the 
right level of isolation between blocks. When we have done that, it 
might be clearer exactly what constitutes the core, and then we can 
maybe factor out the core to a separate jar, but right now the border 
seem to fuzzy to be worthwhile keeping IMHO.

/Daniel