Mladen Turk wrote:
Costin Manolache wrote:
There are few issues and questions, I'm not sure its as simple as it
looks
:-)
For new development - are you going to make changes in both branches ? I
assume there will be
features that can only be done in 1.3.
Right.
1.1.x will be in bug fixing m
Ok, +1.
My remaining question - is it possible to generate a .so file for the JNI
library that includes both APR and JK ( or
2 libraries - in a way that the apr library won't conflict with an older
pre-installed version ) ?
Costin
On Fri, Oct 3, 2008 at 12:12 PM, Mladen Turk <[EMAIL PROTECTED]>
Costin Manolache wrote:
What is the apr version in common linux distros ?
Depends, Httpd 2.2.+ relies on APR 1.3. SVN as well,
so eventually distros will pick it up.
Well, that's a bit tricky - people don't upgrade prod servers easily.
My concern is mostly about possibility for binary r
On Fri, Oct 3, 2008 at 10:43 AM, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
>
>> There are few issues and questions, I'm not sure its as simple as it looks
>> :-)
>>
>> For new development - are you going to make changes in both branches ? I
>> assume there will be
>> feature
Costin Manolache wrote:
There are few issues and questions, I'm not sure its as simple as it looks
:-)
For new development - are you going to make changes in both branches ? I
assume there will be
features that can only be done in 1.3.
Right.
1.1.x will be in bug fixing mode
Also, if we hav
There are few issues and questions, I'm not sure its as simple as it looks
:-)
For new development - are you going to make changes in both branches ? I
assume there will be
features that can only be done in 1.3.
Also, if we have separate releases of APR - are we going to release binaries
? For bo
Rainer Jung wrote:
Mladen Turk schrieb:
The native external is used in the dist.xml build file in order to
include the tcnative sources in the TC src release. So either we need to
adjust this part of TC build process, or simply switch the external for
TC 6.0.x to the 1.1 branch (and keep TC trun
On Oct 3, 2008, at 9:33 AM, Yoav Shapira wrote:
On Fri, Oct 3, 2008 at 1:56 AM, Mladen Turk <[EMAIL PROTECTED]> wrote:
Hi,
I'd like to create a branch of connectors
for native component so it depends on the
new APR 1.3.x API
+1.
Like Mark, I'm also OK with removal.
+1
Mladen Turk schrieb:
> Hi,
>
> I'd like to create a branch of connectors
> for native component so it depends on the
> new APR 1.3.x API
> The new API offers some essential features targeted
> explicitly for pool issues usage in
> high level languages like Java.
>
> So, my idea is to branch the c
On Fri, Oct 3, 2008 at 1:56 AM, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'd like to create a branch of connectors
> for native component so it depends on the
> new APR 1.3.x API
+1.
Like Mark, I'm also OK with removal.
Yoav
--
Mladen Turk wrote:
> Hi,
>
> I'd like to create a branch of connectors
> for native component so it depends on the
> new APR 1.3.x API
> The new API offers some essential features targeted
> explicitly for pool issues usage in
> high level languages like Java.
>
> So, my idea is to branch the cur
+1
2008/10/3 Mladen Turk <[EMAIL PROTECTED]>:
> Hi,
>
> I'd like to create a branch of connectors
> for native component so it depends on the
> new APR 1.3.x API
> The new API offers some essential features targeted
> explicitly for pool issues usage in
> high level languages like Java.
>
> So, my
Hi,
I'd like to create a branch of connectors
for native component so it depends on the
new APR 1.3.x API
The new API offers some essential features targeted
explicitly for pool issues usage in
high level languages like Java.
So, my idea is to branch the current trunk
as connectors/branches/othe
13 matches
Mail list logo
