cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Splitting core
Date Thu, 14 Dec 2006 12:35:43 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> Daniel Fagerstrom skrev:
>>> After my refactoring of the pipelines it is hopefully possible to start 
>>> factoring out the pipelines and the sitemap components to own modules. 
>>> And thus start the work on making the core more strictly layered.
>>> There are probably many more things that needs to be handled to make 
>>> this possible. I think the best way to find out is to start working on 
>>> it. So I plan to to that, if no ones protest.
>>> My plan is to start factoring out a "cocoon-pipeline-api" containing 
>>> ProcessingPipeline and all interfaces that it depends on.
>> I have a working cocoon-pipeline-api on my computer now and will commit 
>> it in the next few days if no one protests. It looks like this:
> I have no real objects, although I have the feeling that we will never
> release a final 2.0.
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 

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

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?

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


View raw message