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 not
mandatory module for Tomcat and it is somehow independent fro
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 not
mandatory module for Tomcat and it is somehow independent from
tomcat.
tcnative builds
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 not
mandatory module for Tomcat and it is somehow independent from tomcat.
tcnative builds contain cryptosoftwa
> 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)
Go
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 not
mandatory module for Tomcat and it is somehow independent from tomcat.
tcnative builds contain cryptosoftware (openssl) and that means
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 not
mandatory module for Tomcat and it is somehow independent from tomcat.
tcnative builds contain cryptosoftware (openssl) and that means
jean-frederic clere wrote:
Mark Thomas wrote:
jean-frederic clere wrote:
I think that is all working around the fact that tcnative is not
mandatory module for Tomcat and it is somehow independent from tomcat.
tcnative builds contain cryptosoftware (openssl) and that means they
may not be av
Mark Thomas wrote:
jean-frederic clere wrote:
I think that is all working around the fact that tcnative is not
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
jean-frederic clere wrote:
I think that is all working around the fact that tcnative is not
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 that d
Guenter Knauf wrote:
Hi,
Still need to figure out what to do with all the other versions in
a.o/dist though - we can't just leave them.
well, someone needs to commit them all to a project's SVN subdir like
'tagged_tarballs' or such;
this way the history would stay available...
Hi
I think t
Filip Hanik - Dev Lists wrote:
Mladen Turk wrote:
Filip Hanik - Dev Lists wrote:
you're other option is to just vote on tcnative separately, and that
way utilize all the ASF mirrors and release sites
But that is exactly what we should *not* do.
Tomcat comes with it's native, so if you upgra
Hi,
> Still need to figure out what to do with all the other versions in
> a.o/dist though - we can't just leave them.
well, someone needs to commit them all to a project's SVN subdir like
'tagged_tarballs' or such;
this way the history would stay available...
Guen.
--
Mladen Turk wrote:
Guenter Knauf wrote:
just an idea / suggestion:
isnt it usable for the release process that you create a place in SVN
where you commit the tarballs, and then download them via http from
there instead from a directory location?
Finally, an interesting idea.
You are right.
William A. Rowe, Jr. wrote:
I understand the desire to make this
"easy" for the RM, and the statement that its "useless" from
outside of tomcat, but the simple fact is that this is a
released unit of code, separately versioned, determined before
the "real release" of Tomcat is designated.
Look
Guenter Knauf wrote:
Hi Mladen,
But that is exactly what we should *not* do.
Tomcat comes with it's native, so if you upgrade the
Tomcat, upgrade its native as well (if changed)
Like said, all that can be easy done by simply
extending requirements for building Tomcat release.
One will need Py
Guenter Knauf wrote:
just an idea / suggestion:
isnt it usable for the release process that you create a place in SVN where you
commit the tarballs, and then download them via http from there instead from a
directory location?
That would work. We use the same process for the windows service b
Mladen Turk wrote:
Because it's native and the one that makes a release needs
some extra prerequisites to build it.
Part of this confusion is that projects never vote on binary
artifacts, they vote on source code releases.
Because the sources land in tags/ and a tarball, I'd strongly
consider
Hi Mladen,
> But that is exactly what we should *not* do.
> Tomcat comes with it's native, so if you upgrade the
> Tomcat, upgrade its native as well (if changed)
> Like said, all that can be easy done by simply
> extending requirements for building Tomcat release.
> One will need Python and a set
Filip Hanik - Dev Lists wrote:
Mladen Turk wrote:
Filip Hanik - Dev Lists wrote:
you're other option is to just vote on tcnative separately, and that
way utilize all the ASF mirrors and release sites
But that is exactly what we should *not* do.
Tomcat comes with it's native, so if you upgra
Mladen Turk wrote:
Filip Hanik - Dev Lists wrote:
you're other option is to just vote on tcnative separately, and that
way utilize all the ASF mirrors and release sites
But that is exactly what we should *not* do.
Tomcat comes with it's native, so if you upgrade the
Tomcat, upgrade its nativ
Mladen Turk wrote:
It would mean that you will need *nix for building
the Tomcat release, but that's fine with me.
If the Tomcat RM's are fine with that, it's a very
simple task.
That means we require the release to be built on Windows so we can built
the installer and on *nix for native. Ess
Filip Hanik - Dev Lists wrote:
you're other option is to just vote on tcnative separately, and that way
utilize all the ASF mirrors and release sites
But that is exactly what we should *not* do.
Tomcat comes with it's native, so if you upgrade the
Tomcat, upgrade its native as well (if change
Filip Hanik - Dev Lists wrote:
you're other option is to just vote on tcnative separately, and that way
utilize all the ASF mirrors and release sites
A vote seems to be the quickest and best solution along with standard
releases (like mod_jk) going forward.
It isn't like there is a lack of p
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
OK if you insist.
The *Foundation* insists ;-)
OK ;)
I suppose we can then use the src tarball from the heanet.ie
site (used by the installer BTW) instead dist site.
Or you can remove the file to /dev/dist/, and hold a release vote alread
you're other option is to just vote on tcnative separately, and that way
utilize all the ASF mirrors and release sites
Filip
Mladen Turk wrote:
Mark Thomas wrote:
Mladen Turk wrote:
Henri Gomez wrote:
No, like said, Tomcat Native is voted *together*
with Tomcat version that contains it.
M
Mladen Turk wrote:
OK if you insist.
The *Foundation* insists ;-)
I suppose we can then use the src tarball from the heanet.ie
site (used by the installer BTW) instead dist site.
Or you can remove the file to /dev/dist/, and hold a release vote already?
> Or we can have it inside
> http:/
Mark Thomas wrote:
Mladen Turk wrote:
Henri Gomez wrote:
No, like said, Tomcat Native is voted *together*
with Tomcat version that contains it.
May be but the version numbers are different.
It seems very similar to mod_jk in my opinion, since it's a part of
Tomcat but not mandatory.
But i
Mladen Turk wrote:
Henri Gomez wrote:
No, like said, Tomcat Native is voted *together*
with Tomcat version that contains it.
May be but the version numbers are different.
It seems very similar to mod_jk in my opinion, since it's a part of
Tomcat but not mandatory.
But it's not. We don't ha
Henri Gomez wrote:
No, like said, Tomcat Native is voted *together*
with Tomcat version that contains it.
May be but the version numbers are different.
It seems very similar to mod_jk in my opinion, since it's a part of
Tomcat but not mandatory.
But it's not. We don't have announce for Tomc
> No, like said, Tomcat Native is voted *together*
> with Tomcat version that contains it.
May be but the version numbers are different.
It seems very similar to mod_jk in my opinion, since it's a part of
Tomcat but not mandatory.
Just my 0,01 EUR
---
Henri Gomez wrote:
Tomcat native is not separate product, but rather an integral
part of Tomcat distribution. The need for tag is needed because
we'd need to put some serious native part build (as well as tools)
when building Tomcat. Perhaps some day we'll do that, so we can
tag the Tomcat togeth
> Tomcat native is not separate product, but rather an integral
> part of Tomcat distribution. The need for tag is needed because
> we'd need to put some serious native part build (as well as tools)
> when building Tomcat. Perhaps some day we'll do that, so we can
> tag the Tomcat together with nat
Mark Thomas wrote:
Have I missed the 1.1.12 native release vote?
No :)
Without a vote, these files need to be removed. In case I have missed
the vote, I will wait 24 hours to be corrected before deleting the files
from dist and the archives (assuming I have enough karma).
Native tag
All,
Have I missed the 1.1.12 native release vote?
http://archive.apache.org/dist/tomcat/tomcat-connectors/native/ shows a
1.1.12 but neither my recollection nor a check of the archives shows a
release vote for these files. The files are also on the mirrors.
Without a vote, these files need
34 matches
Mail list logo
