On 02.01.2009 11:57, Mladen Turk wrote:
> Rainer Jung wrote:
>> 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".
>>
>
> Like now, in connectors/jni/java

Tomcat 6 and trunk do *not* use connectors/jni/java. They use private 
copies of these files, which are not svn externals. Only TC 5.5 uses the 
above path via svn externals.

Those copies are in

tomcat/trunk/java/org/apache/tomcat/jni/
and
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/jni/

>> 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.
>>
>
> It doesn't mater if the API is stable or not.
> Tomcat will just depend on tomcat-native-1.xx.noarch.bin.zip and use the
> pre-compiled .jar
> (like any other jakarta-commons component for example)

OK, I think that's exactly what I meant with a) and with removing the 
Java class copies from the Tomcat source tree. The jar file with the 
o.a.tomcat.jni classes would be part of the tomcat-native binary release 
(which it is not now) and the Tomcat build procedure would download the 
tomcat-native binary release and unpack like it does for commons.

Regards,

Rainer

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