tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: NIO Connector, please review
Date Mon, 19 Jun 2006 19:35:34 GMT
On 6/19/06, Mladen Turk <mturk@apache.org> wrote:
>
> Costin Manolache wrote:
> >
> > Of course - all stuff must compile at least - but I don't think it's a
> > reasonable
> > requirement to have all modules or other things that are not part of
> tomcat
> > tested  in order to do a release.
> >
>
> But in that case, they could not be the part of the Tomcat code.
> If you think that we can release the clustering independently of
> the Tomcat, then it's a separate project that only uses Tomcat,
> and it is not part of it. The same applies to any other 'module'.


What do you mean ?  Tomcat code ( i.e. whatever modules the tomcat pmc
maintains ) can include multiple componets, as long as they are within the
scope.  Admin, cluster, etc are closely related with tomcat - I don't think
you
are arguing that they are not in the project scope.

Tomcat code includes all the files in all svn repositories - and we can pick
and chose what we release and how.

Yes, the cluster/admin/etc can live on sourceforge or a separate apache
project, but
it's our choice if we want it in tomcat codebase, and how to release it.

The thing I like with TC6 is that it treats its codebase as an
> entity. Having separate independent 'modules' makes it even
> worse compared with the current stuff we have.


I agree - it's good to have a single codebase !

But I strongly disagree that we should have one big bloated release that
includes
everything in the codebase.



We can discuss what exactly makes the Tomcat. If it's not the
> Clustering or Admin or what ever, then they'll need to be the
> separate projects that 'use Tomcat', and then and only then,
> we can version them separately.


There is no requirement for a source file to be in a separate svn module
or tree, or even separate project in order to have it's own separate release
version and cycle.

You can have files in the svn that are not included in the release, you can
have
files that are used in a different release, you can have multiple labels.

There are many apache projects that release more than one thing, and code
organization ( as svn repositories or source trees ) is orthogonal to
release content
and organization.

( and there is no rule that a release of cluster or admin must support only
the last
version of tomcat - but that's yet-another independent issue )

Costin

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