tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <>
Subject Re: Native 1.1.12 release
Date Tue, 15 Jan 2008 14:12:42 GMT
jean-frederic clere wrote:
> Mladen Turk wrote:
>> jean-frederic clere wrote:
>>> Mladen Turk wrote:
>>>> jean-frederic clere wrote:
>>>>> Mark Thomas wrote:
>>>>>> jean-frederic clere wrote:
>>>>>>> I think that is all working around the fact that tcnative is
>>>>>>> mandatory module for Tomcat and it is somehow independent from

>>>>>>> tomcat.
>>>>>>> tcnative builds contain cryptosoftware (openssl) and that means

>>>>>>> they may  not be available for download in the ASF site. But
>>>>>>> doesn't prevent us from releasing tcnative sources.
>>>>>>> tcnative is not very visible and I am +1 for changing this. 
>>>>>>> (updating site and tc build).
>>>>>> This is my preferred option. There would also need to be a release

>>>>>> vote for all the src distros on a.o/dist.
>>>>> And we should remove any of the files that doesn't get voted.
>>>>>> If there is some show stopper issue with releasing native 
>>>>>> separately that I haven't seen, then I am happy as the svn 
>>>>>> solution as an alternative.
>>>>> I am now working on arranging trunk to use a separated tcnative. 
>>>>> Part of the logic is already in the actual code.
>>>> I can only tell you that I'll vote -1 on any attempt
>>>> to make the tomcat native connector as separate product.
>>>> We should better remove it altogether from the Tomcat distribution
>>>> until we either find a way to build it together with Tomcat
>>>> or just forget about it.
>>> The actual situation is bad:
>>> - a source tarball contains the tcnative sources corresponding to the 
>>> tomcat tag.
>>> - a binary tarball contains the tcnative sources (in a tarball) 
>>> corresponding to the 
>>> /dist/tomcat/tomcat-connectors/native/tomcat-native-x.y.z-src.tar.gz 
>>> (1.0.10 actualy)
>>> We have to fix that.
>> Right, I agree.
>> The easiest solution would be to just create configure and put
>> it inside the SVN,
> configure is a generated file and depend on the apr version...
> then probably we have to add apr sources...

No. Apr sources are needed for creating configure.
Right now any 1.2.x version will do, so we can update
it the same way we choose what APR source version we'll
use anyhow for running buildconf.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message