Simone Gianni skrev:
Daniel Fagerstrom wrote:
The pipeline layer consists of:
cocoon-pipeline-api - Interfaces: ProcessingPipeline, sitemap
component and basic XML interfaces, the environment abstraction,
caching interfaces and needed exceptions.
cocoon-pipeline-impl - The various implementations of
ProcessingPipeline together with classes that they depend on and
various abstract classes for the sitemap components.
cocoon-pipeline-components - generators, transformers, serializers,
readers, some sources and xpointer and xslt components.
Here probably some of the abstract classes should be moved to the api
module, but I didn't want to make the api to heavy in the first step.
Also the impl module probably contains components and utility class
that would be better to factor out to own modules.
Maybe the component module should be split into a base and an optional
module?
Right now the dependency graph is:
api -> impl -> components
while it rather should be
api -> impl
api -> components
Hi Daniel, very good work!
Thanks :)
But I'm missing something : if *-impl
contains abstract classes for components, and *-components contains that
components, how can they not depend on the abstract classes they extend?
You are absolutely right. Abstract base classes intended for reuse
should be part of the API. But as we, IMHO, severely overuse abstract
base classes in and as the abstract base classes would increase the
number of dependencies for the API and as we are trying to decrease the
Avalon dependencies, I felt rather reluctant to put all the abstract
classes in the API. And because of that the components depends on the
impl instead of just the API. I hope we will be able to get to the point
where the abstract base classes have more reasonable dependencies and
can be moved to that API or maybe some pipeline util module.
/Daniel
