On 09.10.2006 23:03, Antonio Gallardo wrote:
I am thinking in 2.2 too. The above reference to 2.1 is just a sample of what we are repeating for 2.2. Because we claim 2.1 is java 1.3 when it fact few of us care about this compatibility and some blocks does not compile at all. This somehow makes us look like a buggy project. As a sample try to download the 2.1 and try to compile it as is shipped in java 1.3 it simply does not compiled.
It should. Everything else is a bug. The JCR block, known to be not 1.3 compatible is switched off. IIRC this is due to the API only available as 1.4 jar, isn't it?
"Nobody cares about it." Many (I would said: "most") of the cocoon developers does not have a java 1.3.1 version installed in his machines to compatibility test the code
That might be true. But as soon as we get aware of such a problem it gets fixed.
But this effort is worthless since also looks our user base also does not use this days java 1.3 at all."
If this would be true we would not get informed about such errors. If this would be true Cocoon could not be seen as a buggy project as nobody would notice the problems. Sorry, but you contradict yourself.
The proof of that is new qdox which API changed hence as a user it does not easy to switch unless he maintains his own components.
Where is the problem? As soon as we have released 2.2 and the blocks they can start independent release cycles.
Another perhaps more used component (I would said a critical one) is ehcache, each new version often introduce new API.
Though you take it just as an example I can say that ehcache won't get a problem that fast. They also care for their users, which is besides Cocoon for example Spring. Spring even claim 1.3 compatibility with their latest 2.0 release. So ehcache will provide 1.4 compatibility probably for a long time.
Sorry, but you have no new points. Jörg
