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
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
_________________________________________________________________________
