Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of joerg.heinicke@gmx.de designates
 213.165.64.20 as permitted sender)
Message-ID: <452ADB45.2030906@gmx.de>
Date: Tue, 10 Oct 2006 01:29:09 +0200
From: Joerg Heinicke <joerg.heinicke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
References: <4529C9AC.60600@agssa.net>
	 <f767f0600610090902w4ef88d80l135eb787b9eebb87@mail.gmail.com>
	 <452A7F44.3020300@agssa.net>
 <f767f0600610091122o47e3d36dv207b317e75c7a8f1@mail.gmail.com>
 <452AB92D.7010001@agssa.net>
In-Reply-To: <452AB92D.7010001@agssa.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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