cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: Splitting core
Date Thu, 14 Dec 2006 14:24:18 GMT
Daniel Fagerstrom wrote:
> Although I saw in a later comment that the above wasn't directed primary 
> towards the splitting, it is a very relevant question in this context as 
> well.
> 
> I think that a clearly layered architecture will make it much easier for 
> other people to contribute to stabilizing the core. Splitting the core 
> is also means that we test that we follow our APIs, which also should 
> stabilize Cocoon.
Yes, I agree.

> My hope is that it will not affect the code much at all. If it does and 
> it seem like it will delay a release, we can stop the activity.
To me, it raises the question how long will it take to have clear
separate layers (especially if there are only a few of us working on
this). Or putting it the other way round: I don't think that your
current proposals and actions delay the release, but the question is
how far can we get if we release a RC of 2.2 early january?

> 
> So my hope is that it will contribute towards getting a stable final 2.2.
>> Anyway, I think we should find a better solution for the factories
>> (GeneratorFactory etc.). I think that this can be handled by spring
>> transparently without the need of an addition factory interface.
>>   
> Agree. Do you have any specific solution in mind?
I think we could just use leave this up to spring, which means either
the generator is implement using avalon pooling, or a new instance is
created each time, or a factory method (e.g. a static one) is configured
in spring etc. This is transparent to the client code.
The only problem is clean up. We should add a "cleanup sitemap
component" marker interface which is called, if the component implements
this, after the pipeline has been processed.

> 
>> For a real pipeline api I would love to have the dependencies to Avalon
>> removed, like the Parameters object or even the SourceResolver used in
>> the setup method.
>>   
> Agree as well, but as the pipeline APIs are so central to everything, 
> that would need to be part of 3.0.
Hmm, we could go the dual api way. Introduce a new pipeline api, but
still support the old one.

Carsten
-- 
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Mime
View raw message