On Mar 24, 2004, at 3:54 AM, Joerg Heinicke wrote:
On 20.03.2004 21:42, leo leonid wrote:no need, I was *not* complaining, as you see...
Exactly, nobody, neither I did, that was not my concern. Please take a moment and try to see it from my perspective.
I did not expect that you or anybody specific answers on this temporary problem, but *that* anybody answers.
I use the CVS version for developing, and I'm aware of the implications, that things can change or even break by the ongoing development process. May be it is just a coincidence, or it may be due to the fact that you are one of the most active committers - anyhow - your last commits put my projects in a fine mess.
Sorry for that.
Well, this happens, it's not the point, absolutely no problem, in general.
Whereas I do have some objections, but these only concern the avoidable parts of the mess. That's when you _see_ your patch isn't mature at all and it breaks core parts of cocoon,
This was the reason that I sent a mail to the list.
Subject: "AbstractXMLProducer patch consequences"
I assume that people living from CVS also read the developers list.
I do. But IMO you can't assume your mail (with that subject) could get the needed visibility.
Therefore I would not update my Cocoon if I knew that something is broken. Of course we avoid non-working as far as possible, but there also must be some time to discuss about things. If something is broken this highers the need for discussion while maybe somebody would not answer if it's not broken (lazy ass syndrom, "let it as it is").
I think I see your point, but I ask you to keep proportions in mind.
/leo
(the following seems to be a misunderstanding, probably due to my bad english skills, sorry!)
or spoils users project directories (as with bug 27600)
Huh? Sorry, but here I feel innocently accused. *I* added the behaviour that the source directory is not touched at all until you choose otherwise after the complete update worked. Furthermore this helper target was only a few days old, it's not something that breaks anything (i.e. is needed at run time) and was easily changeable by the developer using the target by putting the xslt part into comments. Here the need to revert was very much lower than for the above XSP problem IMO.
and you still don't consider to revert it.
Why? Are you still not satisfied with the current solution making the xslt part optional? (You wrote the above two days after I added this.)
Anyway, glad to hear you fixed it. Thanks.
No problem.
Joerg
