Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <495DDD3D.5020207@kippdata.de>
Date: Fri, 02 Jan 2009 10:24:13 +0100
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1
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> <495DC178.5090505@apache.org>
In-Reply-To: <495DC178.5090505@apache.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

On 02.01.2009 08:25, Mladen Turk wrote:
> 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.

I'm not sure I exactly understand this: when using b), the Java classes 
will be kept where? If we don't change anything, they (copies of them) 
are already part of TC trunk and TC 6, so need to "populate".

>> 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.

I'm not sure, if the separate release cycles prevent a). My impression 
is, that the Java API of tcnative (org.apache.tomcat.jni) is pretty 
stable, so the need for releasing versions of that when releasing a 
version of Tomcat should not be the regular case.

Regards,

Rainer

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