Costin Manolache wrote:
Will we have installers for it ?
for the moment a tarball or zip file should be ok, shouldn't it?
Will the installer/release include the
associated libapr ?
Yes.
What about openssl?
I assume both native and java
code will be included ?
I am not sure of that... A
On Tue, 2008-01-15 at 16:19 +0100, jean-frederic clere wrote:
[X] Make tcnative release independent from tomcat release and add the
corresponding pages in http://tomcat.apache.org/connectors-doc/
[ ] Remove existing tcnative releases. (others are using them).
Rémy
Will we have installers for it ? Will the installer/release include the
associated libapr ? I assume both native and java
code will be included ? What additional docs will be needed ? Will tomcat
releases bundle it, or just require to download it separately ?
It would be great to have it as
On Tue, 2008-01-15 at 16:19 +0100, jean-frederic clere wrote:
[X] Make tcnative release independent from tomcat release and add the
corresponding pages in http://tomcat.apache.org/connectors-doc/
[ ] Remove existing tcnative releases. (others are using them).
Peter
[X] Make tcnative release independent from tomcat release and add the
corresponding pages in http://tomcat.apache.org/connectors-doc/
I'd like this idea.
jk or tcnative are part of the 'tomcat' chain and could (should) be
packaged independently.
Their life cycle is not the same.
A +1
On Jan 15, 2008 10:19 AM, jean-frederic clere [EMAIL PROTECTED] wrote:
[ X ] Make tcnative release independent from tomcat release and add the
corresponding pages in http://tomcat.apache.org/connectors-doc/
I like modularity.
Yoav
Hi,
I think that the tcnative releases should be independent from tomcat.
There are several reasons:
- The native code is in /tomcat/connectors/trunk/jni/native and it
checked out via links in tc trunk/6.0.x/5.5.x.
- The logic to have tcnative independent is already in the code of trunk
and
jean-frederic clere wrote:
Mladen Turk wrote:
jean-frederic clere wrote:
Hi,
I think that the tcnative releases should be independent from tomcat.
There are several reasons:
- The native code is in /tomcat/connectors/trunk/jni/native and it
checked out via links in tc trunk/6.0.x/5.5.x.
-
I'd vote the same given the new choice. I'm also willing to help with
putting docs up, etc.
On Jan 15, 2008 10:47 AM, Mladen Turk [EMAIL PROTECTED] wrote:
jean-frederic clere wrote:
Mladen Turk wrote:
jean-frederic clere wrote:
Hi,
I think that the tcnative releases should be
Mladen Turk wrote:
jean-frederic clere wrote:
Hi,
I think that the tcnative releases should be independent from tomcat.
There are several reasons:
- The native code is in /tomcat/connectors/trunk/jni/native and it
checked out via links in tc trunk/6.0.x/5.5.x.
- The logic to have tcnative
jean-frederic clere wrote:
Hi,
I think that the tcnative releases should be independent from tomcat.
There are several reasons:
- The native code is in /tomcat/connectors/trunk/jni/native and it
checked out via links in tc trunk/6.0.x/5.5.x.
- The logic to have tcnative independent is already
Yoav Shapira wrote:
I'd vote the same given the new choice. I'm also willing to help with
putting docs up, etc.
Can we guys discuss this more before putting any vote?
Vote means we cannot make any consensus, so we need
to make a 'by majority rule' decision.
The whole discussion started less
On Tue, 2008-01-15 at 16:19 +0100, jean-frederic clere wrote:
Hi,
I think that the tcnative releases should be independent from tomcat.
There are several reasons:
- The native code is in /tomcat/connectors/trunk/jni/native and it
checked out via links in tc trunk/6.0.x/5.5.x.
- The logic
Remy Maucherat wrote:
The native component can be used by many Tomcat releases, and has been
tagged and released independently. Of course, it is often done in sync
with Tomcat to introduce new APIs, but overall it's quite similar to
mod_jk releases.
But it's not even close to the mod_jk
Yoav Shapira wrote:
I'd vote the same given the new choice. I'm also willing to help with
putting docs up, etc.
On Jan 15, 2008 10:47 AM, Mladen Turk [EMAIL PROTECTED] wrote:
jean-frederic clere wrote:
Mladen Turk wrote:
jean-frederic clere wrote:
Hi,
I think that the tcnative releases
Mladen Turk wrote:
Remy Maucherat wrote:
The native component can be used by many Tomcat releases, and has been
tagged and released independently. Of course, it is often done in sync
with Tomcat to introduce new APIs, but overall it's quite similar to
mod_jk releases.
But it's not even
On Tue, 2008-01-15 at 17:54 +0100, Rainer Jung wrote:
Looking at it's formal qualities, it already has some properties of such
a product:
- the API between tcnative and the component using it seems stable
- When we have a problem in tcnative, we fix it there and allow TC users
to update
Remy Maucherat wrote:
(for example, existing Tomcat
users will be able to take 1.1.12 and use it with older Tomcat releases
to fix a bug), so it would need a release vote and separate tagging.
Sure, the same can be done with commons-logging.jar from
any future version I suppose ;)
Anyhow,
Remy Maucherat schrieb:
I don't think that it needs to be managed as a full project (and it does
not have 3 developers). However, it still looks as a release of
something separate than a Tomcat release (for example, existing Tomcat
users will be able to take 1.1.12 and use it with older Tomcat
19 matches
Mail list logo
