[EMAIL PROTECTED] wrote:
> (Nested comment is Peter's, I think)
> > No - What I mean is, why don't you glom Catalina and tomcat together
> > into one big CVS tree? I mean, it's only a version difference, right?
>
> They used to sit in the same CVS tree.
>
And they used to share code, too (in the utilities packages) ... until Catalina
started getting bit every time a refactoring was done on the utilities code.
Once Catalina became 100% separate code, there was no practical reason to keep
them together. And once Catalina was approved for Tomcat 4.0, there was no
reason to keep it under a "proposals/catalina" directory in the main tree any
longer either.
>
> But there is one thing you forgot - a component needs first to be
> "aproved" - you can't have jakarta-DBCP until the library commiters agree
> that whatever code we have is ready and mets the requirements.
>
> Until this happens - all DBCPs are equal.
>
Isn't that true afterwards as well? If we adopt that part of the PERL
philosophy ("there's more than one way to do it"), you could still reasonably
have 2+ (although "+" is unlikely in reality) product-quality, supported,
shareable, reusable, DBCP implementations that have different feature sets.
As another example of a situation where we are going to want this -- consider
that some projects desire to (or must) maintain JDK 1.1 compatibility.
Sometimes you can work around that through clever APIs, but sometimes you can't
(for example, the JDBC 2.0 APIs depend on a java.util.Map). For a sufficiently
small component, it might make perfect sense that have two components that
provide similar functionality -- one JDK 1.1 compliant and one requiring Java2.
>
> Costin
Craig
