tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <hgo...@slib.fr>
Subject RE: #define JK_VERSION in j-t-c (doesn't exist)
Date Fri, 15 Jun 2001 15:02:26 GMT
>> Why did we start j-t-c ?
>> 
>> - a connector is mainly native code, how to build apxs or 
>use autoconf
>>   has nothing to do in tomcat dev/users list. I hope we could have a
>>   separate dev/users lists later.
>> 
>> - mod_jk is in TC 3.2 and 3.3. Thegeneral rules for TC 3.2 
>is to freeze
>>   features and only correct bugs.
>>   I add some features (AP2.0 support, TimeStamp in log, more 
>robust handling
>> 
>>   of Tomcat failure or reboot) in the mod_jk for TC 3.3 and 
>now the version
>>   have diverged :!
>>   Frankly having 2 code branchs to support is too just much job.
>>   And then Kevin proposed the ajp13 port to TC 4.0, and so 
>the need for
>>   an independant repository
>> 
>> - a connector could/should be independant from the core container
>>   and we could have a different release rate.
>> 
>> - j-t-c make possible reflexion on how to build connections
>>   common to TC 3.2/3.3/4.0. See the excellent Coyote 
>Proposal which live
>>   now in jtc.
>
>I understand all that, but I'm not quite clear how that negates the
>possible advantage of making it possible to know at compile time which
>version of the jk code is being used, and in general if there is a
>version number at all defining a way of mapping it to a 
>numeric constant also seems to be a good idea. 

We'll keep the idea of version number, cf JF could you add it in version.h.
?
+/- how Apache http team use....

===>

/* Numeric release version identifier: MMNNFFRBB: major minor fix final beta
 * Always increases along the same track as the source branch.
 * For example, Apache 1.4.2 would be '10402100', 2.5b7 would be '20500007'.
 */
#define APACHE_RELEASE 10320100

<===

#define JK_MODULE_RELEASE 10200001	(1.2.0-b1 )

>Is your concern that, if we were to do
>that, the code would end up polluted with many conditionally compiled
>sections making testing and maintenance harder?

Yep

>If nothing else such a constant could be used to throw a compile time
>error if people attempt to build a connector using incompatible shared
>jk code.

Could you develop ?

Mime
View raw message