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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
