You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Filip Hanik - Dev Lists <de...@hanik.com> on 2007/03/27 09:11:14 UTC
6.0.11 anyone
Any thoughts on a 6.0.11 release?
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Henri Gomez <he...@gmail.com>.
Will it be a 6.0.11 beta or a release ?
2007/3/27, Peter Rossbach <pr...@objektpark.de>:
> +1
> the NIO Memory leak fix is very important :-)
>
> Peter
>
>
> Am 27.03.2007 um 15:45 schrieb Filip Hanik - Dev Lists:
>
> > Remy Maucherat wrote:
> >> Filip Hanik - Dev Lists wrote:
> >>> Any thoughts on a 6.0.11 release?
> >>
> >> What would be the main motivation for a new release ?
> > The new Executor
> > Bug fixes
> >
> > Filip
> >>
> >> Rémy
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Peter Rossbach <pr...@objektpark.de>.
+1
the NIO Memory leak fix is very important :-)
Peter
Am 27.03.2007 um 15:45 schrieb Filip Hanik - Dev Lists:
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>>> Any thoughts on a 6.0.11 release?
>>
>> What would be the main motivation for a new release ?
> The new Executor
> Bug fixes
>
> Filip
>>
>> Rémy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by "William L. Thomson Jr." <wl...@gentoo.org>.
On Wed, 2007-03-28 at 14:51 -0600, Filip Hanik - Dev Lists wrote:
> man, you sure like to write.
Doesn't take long to type ;)
> The buildscript command:
>
> ant -f extras.xml
>
> generates two files
> output\extras\tomcat-juli.jar
> output\extras\tomcat-juli-adapters.jar
>
> All i'm asking is that these two get generated at release time
>
> what I'm doing is publishing .jar files to a maven repository for
> containers that use Tomcat embedded or just want to use independent jars
Ok, that makes sense. We are discussing how we can integrate and use
maven with our packaging system on Gentoo. Also need to have an embedded
version of Tomcat available for like JBoss.
> So, apache-tomcat-6.0.11.zip will NOT contain these jars.
Ok great, I am 100% clear now. Thanks and sorry about all that. Despite
us building from source. We try to make the resulting install provide
what upstream does. So if those jars were in there, I would need to
include them. But they won't so I don't ;)
> But they were generated during the build, and is available somewhere so
> that I can run the "mavenize" script, and push those files to ASF's
> maven repository.
I was not clear on the generation vs packaging. Thanks and sorry for
lengths.
--
William L. Thomson Jr.
Gentoo/Java
Re: 6.0.11 anyone
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
man, you sure like to write.
The buildscript command:
ant -f extras.xml
generates two files
output\extras\tomcat-juli.jar
output\extras\tomcat-juli-adapters.jar
All i'm asking is that these two get generated at release time
what I'm doing is publishing .jar files to a maven repository for
containers that use Tomcat embedded or just want to use independent jars
So, apache-tomcat-6.0.11.zip will NOT contain these jars.
But they were generated during the build, and is available somewhere so
that I can run the "mavenize" script, and push those files to ASF's
maven repository.
Filip
William L. Thomson Jr. wrote:
> On Wed, 2007-03-28 at 07:55 -0600, Filip Hanik - Dev Lists wrote:
>
>>
>> sorry you had to go on for such a long rant,
>>
>
> No worries, just providing info that may or may not be know.
>
>
>> no one is asking to bundle or to make dependencies.
>> simply asking that some other packages get built at the same time,
>>
>
> Ok, so I must not be clear on the discussion. It seems like the build
> process of Tomcat was to include some extra jars that would go elsewhere
> in the binary release of Tomcat. But not something that would be a build
> time dependency.
>
> Is that not the case?
>
> Are you just trying to get another Apache project to be released in
> conjunction with Tomcat?
>
> Sorry, just not clear because there were comments about build time
> dependencies. And it was being brought up as part of another release of
> Tomcat. So I understood it to be another jar being included with Tomcat
> that is presently, not, and was in the past.
>
> I have gone and re-read the entire thread several times.
>
> Like the original comment that brought it all up
>
> "oh, and can we have the JULI with support for commons-logging built as
> part of the standard build?"
>
> Is that talking about the build of Tomcat? or build of another
> application? Because the follow up talks about keeping deps to a min,
> and a no nonsense build system for Tomcat.
>
> With the response,
>
> "That doesn't mean that the JAR has to be in the lib directory, all I'm
> asking is that it is generated during our releases"
>
> Which I assume to be Tomcat's lib directory. And the jar would go in
> another directory.
>
> I assume the extras.xml is a build file that will be part of Tomcat's
> build system?
>
> So I am mighty confused as to the discussion being about building other
> packages, that won't be bundled nor a dependency. The dependency part is
> clear. The won't be bundled, and building other packages is not clear.
>
> Will they be a separate bundle or download? Like the old embedded,
> compat stuff, etc.
>
> Sorry if all this is obvious and the plane is just flying over my
> head ;)
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by "William L. Thomson Jr." <wl...@gentoo.org>.
On Wed, 2007-03-28 at 07:55 -0600, Filip Hanik - Dev Lists wrote:
>
> sorry you had to go on for such a long rant,
No worries, just providing info that may or may not be know.
> no one is asking to bundle or to make dependencies.
> simply asking that some other packages get built at the same time,
Ok, so I must not be clear on the discussion. It seems like the build
process of Tomcat was to include some extra jars that would go elsewhere
in the binary release of Tomcat. But not something that would be a build
time dependency.
Is that not the case?
Are you just trying to get another Apache project to be released in
conjunction with Tomcat?
Sorry, just not clear because there were comments about build time
dependencies. And it was being brought up as part of another release of
Tomcat. So I understood it to be another jar being included with Tomcat
that is presently, not, and was in the past.
I have gone and re-read the entire thread several times.
Like the original comment that brought it all up
"oh, and can we have the JULI with support for commons-logging built as
part of the standard build?"
Is that talking about the build of Tomcat? or build of another
application? Because the follow up talks about keeping deps to a min,
and a no nonsense build system for Tomcat.
With the response,
"That doesn't mean that the JAR has to be in the lib directory, all I'm
asking is that it is generated during our releases"
Which I assume to be Tomcat's lib directory. And the jar would go in
another directory.
I assume the extras.xml is a build file that will be part of Tomcat's
build system?
So I am mighty confused as to the discussion being about building other
packages, that won't be bundled nor a dependency. The dependency part is
clear. The won't be bundled, and building other packages is not clear.
Will they be a separate bundle or download? Like the old embedded,
compat stuff, etc.
Sorry if all this is obvious and the plane is just flying over my
head ;)
--
William L. Thomson Jr.
Gentoo/Java
Re: 6.0.11 anyone
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
William L. Thomson Jr. wrote:
> On Tue, 2007-03-27 at 17:45 -0600, Filip Hanik - Dev Lists wrote:
>
>> Remy Maucherat wrote:
>>
>>> Filip Hanik - Dev Lists wrote:
>>>
>>>> oh, and can we have the JULI with support for commons-logging built
>>>> as part of the standard build?
>>>> if, yes, then I will be happy to do it
>>>>
>>> IMO, no. I'd like to keep a no dependencies, no nonsense build :) I
>>> don't see any need to use log4j for Tomcat logging anyway, unless you
>>> like running into problems.
>>>
>> it's more about being able to publish all our packages consistently.
>>
>
> That is understandable.
>
>
>> For example, Geronimo, needs to be able to have a unified logging
>> system, and they do, commons logging.
>> And right now, since those packages are not part of an official release,
>> I can't publish that JAR unless I do it manually. I'd like to be able to
>> publish the actual JAR out of the release.
>>
>
> IMHO and pretty much the Gentoo Linux Java philosophy is bundled stuff
> is bad. FOSS Java apps tend to do it more than others. Please consider a
> slightly different viewpoint. But surely not trying to debate, or etc.
>
> Anytime deps are bundled as part of a release, you are locked into that
> version. If there are bug fixes and other releases. They don't tend to
> make it into other applications. Take Netbeans for example, current 5.5
> version ships with a now outdated version of Tomcat 5.5, I believe
> 5.5.17, might be 5.5.20. Can't recall exactly.
>
> Just to be clear either way, current addition of commons-logging won't
> make much difference for us on Gentoo. Why? Because we install once
> instance of a given library, app or etc. We then provide all apps using
> that library, symbolic links to it said jar file or etc. Providing it's
> API/ABI etc compliant with other dependencies. If dependencies are fixed
> on a particular version. We "slot" it and allow for multiple instances
> to be installed.
>
> In Tomcat sense we install one version of Tomcat that say can be used
> with either Netbeans or Eclipse, in place of any version being shipped.
> ( Although not sure if eclipse plugins or etc ship tc, I know they have
> issues when tc is split via C_HOME/C_BASE as we do on Gentoo )
>
> This allows for easier management. Say in this case, commons-logging has
> a new release. As it's package and updated it's updated for all
> applications using that "slot".
>
> Now one might thing manually fetching a dep to be bad. (On Gentoo it's
> automated) However that also allows end user to make a choice on version
> to use. If it's been some time past primary app release, in this case
> Tomcat. Then it's possible what ever version they ship at the time is
> newer than the bundled version say in a previous Tomcat release.
>
> For a further example take Tomcat's jasper-jdt.jar or should I really
> call it by it's real name, Eclipse JDT. Or at least some of it. Which I
> can understand slimming the package down to all that is necessary. But
> that also means future updates to Eclipse JDT won't make it into Tomcat.
> On Gentoo, I might end up replacing that file with a symlink. For I am
> letting the build system do it's thing and repackage what it needs.
>
> So again not trying to really change the direction or debate this. Just
> providing a different view point. I can also understand our solution is
> quite limited to operating systems that allow for symbolic links. Then
> again from another point of view, could be more that allow for symbolic
> links than not ;)
>
> But in the end bundled stuff is bad IMHO. If it can be avoided it should
> be, and manually fetching deps is not a bad thing. Definitely when it's
> not pertinent to the application. But only a subset that might run on
> the application and want things available about of convenience.
> Consistency again I can understand, but does that mean things have to be
> consistent forever and not subject to change?
>
> Anyway, just some food for thought. Sorry for length, and hijacking
> thread topic a bit. Just felt it was kinda a good time to mention it
> all, since the discussion was along similar lines.
>
sorry you had to go on for such a long rant,
no one is asking to bundle or to make dependencies.
simply asking that some other packages get built at the same time,
Filip
> Thanks for your time :)
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by "William L. Thomson Jr." <wl...@gentoo.org>.
On Tue, 2007-03-27 at 17:45 -0600, Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
> > Filip Hanik - Dev Lists wrote:
> >> oh, and can we have the JULI with support for commons-logging built
> >> as part of the standard build?
> >> if, yes, then I will be happy to do it
> >
> > IMO, no. I'd like to keep a no dependencies, no nonsense build :) I
> > don't see any need to use log4j for Tomcat logging anyway, unless you
> > like running into problems.
> it's more about being able to publish all our packages consistently.
That is understandable.
> For example, Geronimo, needs to be able to have a unified logging
> system, and they do, commons logging.
> And right now, since those packages are not part of an official release,
> I can't publish that JAR unless I do it manually. I'd like to be able to
> publish the actual JAR out of the release.
IMHO and pretty much the Gentoo Linux Java philosophy is bundled stuff
is bad. FOSS Java apps tend to do it more than others. Please consider a
slightly different viewpoint. But surely not trying to debate, or etc.
Anytime deps are bundled as part of a release, you are locked into that
version. If there are bug fixes and other releases. They don't tend to
make it into other applications. Take Netbeans for example, current 5.5
version ships with a now outdated version of Tomcat 5.5, I believe
5.5.17, might be 5.5.20. Can't recall exactly.
Just to be clear either way, current addition of commons-logging won't
make much difference for us on Gentoo. Why? Because we install once
instance of a given library, app or etc. We then provide all apps using
that library, symbolic links to it said jar file or etc. Providing it's
API/ABI etc compliant with other dependencies. If dependencies are fixed
on a particular version. We "slot" it and allow for multiple instances
to be installed.
In Tomcat sense we install one version of Tomcat that say can be used
with either Netbeans or Eclipse, in place of any version being shipped.
( Although not sure if eclipse plugins or etc ship tc, I know they have
issues when tc is split via C_HOME/C_BASE as we do on Gentoo )
This allows for easier management. Say in this case, commons-logging has
a new release. As it's package and updated it's updated for all
applications using that "slot".
Now one might thing manually fetching a dep to be bad. (On Gentoo it's
automated) However that also allows end user to make a choice on version
to use. If it's been some time past primary app release, in this case
Tomcat. Then it's possible what ever version they ship at the time is
newer than the bundled version say in a previous Tomcat release.
For a further example take Tomcat's jasper-jdt.jar or should I really
call it by it's real name, Eclipse JDT. Or at least some of it. Which I
can understand slimming the package down to all that is necessary. But
that also means future updates to Eclipse JDT won't make it into Tomcat.
On Gentoo, I might end up replacing that file with a symlink. For I am
letting the build system do it's thing and repackage what it needs.
So again not trying to really change the direction or debate this. Just
providing a different view point. I can also understand our solution is
quite limited to operating systems that allow for symbolic links. Then
again from another point of view, could be more that allow for symbolic
links than not ;)
But in the end bundled stuff is bad IMHO. If it can be avoided it should
be, and manually fetching deps is not a bad thing. Definitely when it's
not pertinent to the application. But only a subset that might run on
the application and want things available about of convenience.
Consistency again I can understand, but does that mean things have to be
consistent forever and not subject to change?
Anyway, just some food for thought. Sorry for length, and hijacking
thread topic a bit. Just felt it was kinda a good time to mention it
all, since the discussion was along similar lines.
Thanks for your time :)
--
William L. Thomson Jr.
Gentoo/Java
Re: 6.0.11 anyone
Posted by Erik Bertelsen <be...@gmail.com>.
> >
> > I don't see any problem then. Since it is generated during the
> > releases if you type "ant -f extras.xml", it should be possible for
> > the RM to release these extra binaries (at least the binaries which
> > may be legally shipped, or are practical to ship) along with the
> > regular packages.
> yes, this is what I was hoping for. Makes my life so much easier.
yes, please do.
This will make it possible for people using commons-logging as their general
logging framework to continue to doing that (regardless of whether commons-
logging is used with log4j or whatever).
- Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> That doesn't mean that the JAR has to be in the lib directory, all
>> I'm asking is that it is generated during our releases
>
> I don't see any problem then. Since it is generated during the
> releases if you type "ant -f extras.xml", it should be possible for
> the RM to release these extra binaries (at least the binaries which
> may be legally shipped, or are practical to ship) along with the
> regular packages.
yes, this is what I was hoping for. Makes my life so much easier.
Filip
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> That doesn't mean that the JAR has to be in the lib directory, all I'm
> asking is that it is generated during our releases
I don't see any problem then. Since it is generated during the releases
if you type "ant -f extras.xml", it should be possible for the RM to
release these extra binaries (at least the binaries which may be legally
shipped, or are practical to ship) along with the regular packages.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> oh, and can we have the JULI with support for commons-logging built
>> as part of the standard build?
>> if, yes, then I will be happy to do it
>
> IMO, no. I'd like to keep a no dependencies, no nonsense build :) I
> don't see any need to use log4j for Tomcat logging anyway, unless you
> like running into problems.
it's more about being able to publish all our packages consistently.
For example, Geronimo, needs to be able to have a unified logging
system, and they do, commons logging.
And right now, since those packages are not part of an official release,
I can't publish that JAR unless I do it manually. I'd like to be able to
publish the actual JAR out of the release.
That doesn't mean that the JAR has to be in the lib directory, all I'm
asking is that it is generated during our releases
Filip
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by "William L. Thomson Jr." <wl...@gentoo.org>.
On Tue, 2007-03-27 at 23:22 +0200, Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
> > oh, and can we have the JULI with support for commons-logging built as
> > part of the standard build?
> > if, yes, then I will be happy to do it
>
> IMO, no. I'd like to keep a no dependencies, no nonsense build :)
Please and thank you. Tomcat 6.0.x build system and reduced dependencies
is greatly appreciated, and IMHO a step in the right direction.
Not saying not to bundle the stuff, just saying please keep deps to a
minimum and no nonsense build ++ =)
--
William L. Thomson Jr.
Gentoo/Java
Re: 6.0.11 anyone
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> oh, and can we have the JULI with support for commons-logging built as
> part of the standard build?
> if, yes, then I will be happy to do it
IMO, no. I'd like to keep a no dependencies, no nonsense build :) I
don't see any need to use log4j for Tomcat logging anyway, unless you
like running into problems.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
oh, and can we have the JULI with support for commons-logging built as
part of the standard build?
if, yes, then I will be happy to do it
Filip
Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
>>> The new Executor
>>
>> It's a nice feature, but it's not urgent IMO. I'm not that happy
>> about it since it's slow, too.
>>
>>> Bug fixes
>>
>> Ok, but with the latest round of changes you made, I'd rather wait
>> something like one week for some stabilization (the last I've seen is
>> a round of experimental session repl optimizations).
> Sure, a week or so would be good. I just wanted to put 6.0.11 on the
> timetable, and yes, I forgot the NIO memory leak, big one.
>
> Filip
>>
>> Rémy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
>> The new Executor
>
> It's a nice feature, but it's not urgent IMO. I'm not that happy about
> it since it's slow, too.
>
>> Bug fixes
>
> Ok, but with the latest round of changes you made, I'd rather wait
> something like one week for some stabilization (the last I've seen is
> a round of experimental session repl optimizations).
Sure, a week or so would be good. I just wanted to put 6.0.11 on the
timetable, and yes, I forgot the NIO memory leak, big one.
Filip
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> The new Executor
It's a nice feature, but it's not urgent IMO. I'm not that happy about
it since it's slow, too.
> Bug fixes
Ok, but with the latest round of changes you made, I'd rather wait
something like one week for some stabilization (the last I've seen is a
round of experimental session repl optimizations).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Any thoughts on a 6.0.11 release?
>
> What would be the main motivation for a new release ?
The new Executor
Bug fixes
Filip
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> Any thoughts on a 6.0.11 release?
What would be the main motivation for a new release ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Remy,
I know it's not that nice to suggest doing things without helping, but
maybe the missing release notes on the docs web page can be fixed for
6.0.11?
Regards,
Rainer
Filip Hanik - Dev Lists schrieb:
> works for me
>
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>>> Any thoughts on a 6.0.11 release?
>>
>> I propose tagging on monday. The polish patches should be applied
>> before then (like the one which fixes the links in the examples).
>>
>> Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
works for me
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Any thoughts on a 6.0.11 release?
>
> I propose tagging on monday. The polish patches should be applied
> before then (like the one which fixes the links in the examples).
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
On 3/30/07, Remy Maucherat <re...@apache.org> wrote:
> Filip Hanik - Dev Lists wrote:
> > Any thoughts on a 6.0.11 release?
>
> I propose tagging on monday. The polish patches should be applied before
> then (like the one which fixes the links in the examples).
+1.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Remy Maucherat <re...@apache.org>.
Remy Maucherat wrote:
> Ok, I'm done now (after one more changelog update), so I plan to tag
> tonight.
Another round of small updates pushed this a little. New date: next Tuesday.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Takayuki Kaneko <ka...@gmail.com>.
Please fix this issue.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41557
This is a minor issue. But it annoys people who use proxy.
It can be fixed easily.
Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
>> Remy Maucherat wrote:
>>> Filip Hanik - Dev Lists wrote:
>>>> Any thoughts on a 6.0.11 release?
>>>
>>> I propose tagging on monday. The polish patches should be applied
>>> before then (like the one which fixes the links in the examples).
>>
>> Ok, I have a small commit to make to fix a glitch with Comet, but
>> since I don't like last minute commits, I'd like to propose pushing
>> back tagging to tomorrow.
> works for me
Ok, I'm done now (after one more changelog update), so I plan to tag
tonight.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>>> Any thoughts on a 6.0.11 release?
>>
>> I propose tagging on monday. The polish patches should be applied
>> before then (like the one which fixes the links in the examples).
>
> Ok, I have a small commit to make to fix a glitch with Comet, but
> since I don't like last minute commits, I'd like to propose pushing
> back tagging to tomorrow.
works for me
Filip
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Remy Maucherat <re...@apache.org>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Any thoughts on a 6.0.11 release?
>
> I propose tagging on monday. The polish patches should be applied before
> then (like the one which fixes the links in the examples).
Ok, I have a small commit to make to fix a glitch with Comet, but since
I don't like last minute commits, I'd like to propose pushing back
tagging to tomorrow.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: 6.0.11 anyone
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> Any thoughts on a 6.0.11 release?
I propose tagging on monday. The polish patches should be applied before
then (like the one which fixes the links in the examples).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org