cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [PROPOSAL] Micro-Cocoon
Date Sun, 30 Dec 2007 19:58:57 GMT
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> My idea is that profiling should only be an aspect on pipeline processing.
>> In 2.1/2.2 you have to use a different pipeline implementation for
>> profiling - I think we can do better.
> Ahh, got it. If we architect API of pipelines well we will be able to provide
> profiling of processing of particular SAX events in particular components.
> Sounds like a nice idea!
>> Here the idea is putting sitemaps into Spring XML configuration files.
> Was it discussed in the past? Sounds new for me.

This was an idea that I've had just recently ... so no, there is no discussion 
that I could point to.

>> Just to make it clear: this will NOT happen in trunk. But nonetheless, 
>> you're right, we have to coordinate the real big changes very carefully.
> In my opinion it does not matter that much if we do disaster in trunk or in
> whiteboard. If we want other people (or even us) to not lost any clue on
> what's happening and what's expected we must be careful.
>>> It may be that I'm just too young committer and I don't remember how C1.0
>>> -> C2.0 transition has been managed.
>>> Do you have a good plan ? :)
>> A good plan? Don't know ... In contrast to the move from 1.x to 2.0 we
>> start off with the already existing codebase instead of starting off from
>> scratch. Then we can start to refactor without having to care too much
>> about backwards-compatibility. My only goal is that Micro-Cocoon should be 
>> very familiar to somebody who is already using Cocoon 2.2.
> Agreed. Nevertheless, I think it would be the best to produce lots of
> test-cases covering most of what we expected from refactored code. This is
> good for two reasons: a) it could be a chance to have finally a decent
> test-coverage of the most crucial Cocoon bits so costs of future maintence
> can be lowered b) they would provide a good overview on the state of work and
> would secure us from breaking the code too much

Yes, I would like to use tests to specify all the contracts.

For trunk, I'm going to work on a "Cocoon Integration Test" module next. Of 
course it will also be helpful for the work on Micro-Cocoon.

>> Back to your question, I know that it will be very difficult or even 
>> impossible to apply patches to trunk and to whiteboard automatically but I
>> guess that's the price we have to pay.
> I'm not sure if I parse it correctly. What patches exactly do you mean?

Let's assume that you fix some bug in AbstractProcessingPipeline of trunk, you 
can't apply the patch to the Micro-Cocoon branch automatically.

Reinhard Pötz                            Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair

View raw message