"Craig R. McClanahan" wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > (Nested comment is Peter's, I think)
No, mine.
> > > 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.
I was being facetious. My point was that separation of things is good
when they aren't related - that CVS will act as an organizational tool.
Just like you do for Tomcat/Catalina - it makes perfect sense.
>
> >
> > 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.
Yes. The key for me is 'different feature sets'. And nothing about
this dictates that you can't have small DBCP projects that have separate
sets of committers.
To keep this in context, this is what we were discussing [I think ;) ] -
that I see library as as set of mini Jakarta projects, where the Jakarta
conventions and rules apply. One of those mini projects can be Agora,
which has as it's ruleset 'anyone welcome' and 'any subject welcome'.
It would easily be able to co-exist with a formal DBCP project with a
defined set of committers.
> 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.
Sure - there is a good example of 'different' features.
> >
> > Costin
>
> Craig
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
