Ahem, is this *REALLY* that hard to fix?
Ok we fix it today and we release tomorrow
wait, what version of Xalan do we have to include? the cvs (maybe full of bugs) or the latest official release (maybe not backward compatible and will break XUpdate)?
Why does Xalan not provide two "getOpMap" methods (and deprecate the old one) so that everyone can live happily with the old and new code.
IMO it's Xalan's responsability to be backward compatible (and to offer a smooth path) and not ours. That's why I don't want to fix this problem right now.
I agree in general, but I don't agree on this particular case. We are using here an internal Xalan class, nothing exposed as an API or as a contract whatsoever, and I think that every project has a full right to change an internal implementation as long as its public API is uchanged.
Moreover, no one of us (at least no one I'm aware of) never followed the evolution of Xalan nor brought this particular issue to the attention of the Xalan team, so I suspect that no one in Xalan-land is aware of this issue. So it's our fault and our bad.
But then again, the real problem is not us, we could easily patch our code, it's Xupdate that, even after leaving Infozone seems to me a dead horse. Either we step up and try to help the Xupdate team (if there is one) or live with this issue (and this is why I asked the Gump team for advice).
My lazy butt tends to suggest to find a solution for the Gump build, keep our stable Xalan version and start fixing it in a consistent way for 2.0, but I'm biased since I'm using only the XML-RPC API, where we have a servlet with a separate classloader so we are free to use the Xalan version that we want, but this might lead to problems for embedded users.
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. http://www.pro-netics.com
