Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <495DC178.5090505@apache.org>
Date: Fri, 02 Jan 2009 08:25:44 +0100
From: Mladen Turk <mturk@apache.org>
User-Agent: Thunderbird 2.0.0.17 (X11/20080915)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: tcnative API stability/compatibility
References: <495CCAD0.9000605@kippdata.de> <495CFA20.7070404@apache.org>
 <495D018E.9090707@kippdata.de>
In-Reply-To: <495D018E.9090707@kippdata.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Rainer Jung wrote:
> 
> a) bundling native and org/apache/tomcat/jni code in one place in svn 
> and releasing together
> 
> or
> 
> b) separating only the native implementation
>

Option a) was used cause we didn't have separate tcnative
release when it was introduced.
Since this is now a separate downloadable bundle we should
use the option b) and populate Java classes during
download task when building Tomcat.

> 
> Do we want to delete the copies of org/apache/tomcat/jni in TC trunk and 
> 6.0.x and use instead ones downloaded from a tcnative release or an svn 
> external to the new tcnative svn location?
> 
> I tend to suggest a) and also getting rid of the redundant copies of the 
> classes in TC trunk and 6, but I'm not sure if I noticed all implications.
> 

We cannot use that option because of separate release cycles.
I was trying to keep them together, but other folks didn't agree with
that, so now we'll have to choose the option b), which is fine
as well. It needs some build process changes, but that shouldn't
be a problem.

Regards
-- 
^(TM)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org