You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2006/12/13 22:03:26 UTC
Splitting core
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.
That part of the work shouldn't affect anyone else as the API is isn't
supposed to be modified often anyway.
When that is finished we could continue with a couple of implementation
modules e.g. a cocoon-pipeline-components for generators, transformers,
serializers and readers, cocoon-pipeline-impl for the actual pipeline
implementation with supporting classes. And maybe some util module for
generally reusable utility components. What is best here will probably
be much easier when we have when have started the work.
I don't think that this is going to destabilize the trunk or delay the
releases. If it does, I'll postpone the work until later.
WDYT?
/Daniel
Re: Splitting core
Posted by Carsten Ziegeler <cz...@apache.org>.
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/
Re: Splitting core
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
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.
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.
/Daniel
Re: Splitting core
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>
>> I have no real objects, although I have the feeling that we will never
>> release a final 2.0.
>
> I guess you meant cocoon-core-2.2, right?
LOL, yepp (we had similar problems with the first 2.0 release...) :)
>
> I don't see a problem because when Daniel splits up the core modules, this is,
> due to transtive dependencies, completly transparent for somebody who has a
> dependency on cocoon-core.
Ah no, sorry, the comment was not targetted at Daniel and his split up.
It was just a general comment. Sorry for not making this clear.
>
> I think we should schedule a next release of cocoon-core-2.2 (+ all dependencies
> it requires) as soon as we have split up things as Daniel proposed.
>
Great
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Splitting core
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> I have no real objects, although I have the feeling that we will never
> release a final 2.0.
I guess you meant cocoon-core-2.2, right?
I don't see a problem because when Daniel splits up the core modules, this is,
due to transtive dependencies, completly transparent for somebody who has a
dependency on cocoon-core.
I think we should schedule a next release of cocoon-core-2.2 (+ all dependencies
it requires) as soon as we have split up things as Daniel proposed.
- o -
The challange that I see is how we can create good documentation when we have
many small modules - but drawing an analogy to what Daniel said I think that
answering this question will be easier while we are working on it.
Having said this, I will concentrate on documentation and if some time is left,
I will take a look at cocoon-forms.
It would be great if others could work on getting releases of different blocks
out of the door.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Splitting core
Posted by Carsten Ziegeler <cz...@apache.org>.
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:
>
> org/apache/cocoon:
> ProcessingException
>
> components/pipeline:
> ProcessingPipeline
>
> environment:
> Environment
> SourceResolver
>
> generation:
> Generator
> GeneratorFactory
>
> reading:
> Reader
>
> serialization:
> Serializer
> SerializerFactory
>
> sitemap:
> SitemapErrorHandler
> SitemapModelComponent
> SitemapOutputComponent
>
> transformation:
> Transformer
> TransformerFactory
>
> util/location:
> Locatable
> LocatedException
> Location
> LocationUtils
> LocatableException
> LocatedRuntimeException
> LocationImpl
> MultiLocatable
>
> xml:
> XMLConsumer
> XMLPipe
> XMLProducer
>
> And pepends on:
> excalibur-xmlutil:2.1
> avalon-framework-api:4.3
> excalibur-sourceresolve:2.1
>
I have no real objects, although I have the feeling that we will never
release a final 2.0.
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.
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.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Splitting core
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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:
org/apache/cocoon:
ProcessingException
components/pipeline:
ProcessingPipeline
environment:
Environment
SourceResolver
generation:
Generator
GeneratorFactory
reading:
Reader
serialization:
Serializer
SerializerFactory
sitemap:
SitemapErrorHandler
SitemapModelComponent
SitemapOutputComponent
transformation:
Transformer
TransformerFactory
util/location:
Locatable
LocatedException
Location
LocationUtils
LocatableException
LocatedRuntimeException
LocationImpl
MultiLocatable
xml:
XMLConsumer
XMLPipe
XMLProducer
And pepends on:
excalibur-xmlutil:2.1
avalon-framework-api:4.3
excalibur-sourceresolve:2.1
/Daniel