tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <>
Subject Re: NIO Connector, please review
Date Mon, 19 Jun 2006 18:08:15 GMT
On 6/19/06, Mladen Turk <> wrote:
> Costin Manolache wrote:
> >
> > By modules/ I mean mostly release units - so maybe a build.xml to create
> > build and package the module, some readme, manifest,
> etc.  Tomcat  normal
> > release wouldn't include the module, but it can be released
> independently,
> > maybe
> > for multiple versions of tomcat.
> >
> Look, if someone is willing to break the build it will do it
> no mater what. Like said, having multiple builds is fine with
> me, but having multiple builds just for the sake of some broken
> module is not. If the module is part of the Tomcat, then there
> can be no release if its build fails. It is just the same as
> for the Httpd etc.

This is not an issue of 'broken build', it's an issue of release units
and lifecycle.

A module release cycle should not block the release of tomcat - it's just an

optional add-on that has it's own life and version number.

Also, I see no purpose of backporting the modules separately
> to the previous versions. If we have a product, then we can
> either provide the patch to the previous version as a whole,
> or simply say to the people to use the current stable version.
> If the patch will only relate to the module A, then it will
> be treated as a patch to the Tomcat6.x.y no to the module A
> for the Tomcat6.x.y. IMHO that'll be less confusing to the
> end users.

Ok.  That's a separate issue as well, sorry for mixing it up.

What I would like is for tomcat6 release to not include all possible
Maybe for backward compatibility we need to include all that tomcat5
maybe we can move out some large ones or things that are still
refactored ( like cluster support ).

I don't see the benefit of having things like cluster support in the tomcat
release -
if someone does want a cluster, they can easily download an additional jar -
up a cluster involves a lot of work, we won't make it much simpler by
bundling the jar with


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message