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/
