cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: [PROPOSAL] Micro-Cocoon
Date Sun, 30 Dec 2007 19:44:45 GMT
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.

> 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

>> 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
code too much

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

Grzegorz Kossakowski

View raw message