[EMAIL PROTECTED] wrote:
>
> Geir, I guess you may be right - in some cases it may be better to have a
> separate CVS tree and each component and the people working on it should
> decide by themself.
>
> It is wrong to force one way or another.
Wow. Not only did Costin and Craig agree on *two* things, but Costin
and I did on this. Imagine :)
>
> > Further, my opinion is that you simply better have a good reason to
> > duplicate existing function. If you have something to add, go to the
> > existing project. If they don't want it, then you have a good reason to
> > start another one. There will at least be a differentiating factor.
>
> Once again - that may be true, but I hope we all agreed that "agora" is
> open to anything that commiters and projects want to do - regardless of
> "duplication" or other arguments like this.
>
Yes. I agree that Agora should be open to everything and everything no
matter what else is going on in the library. That is the point of the
incubator, isn't it?
That is what I liked about the idea of Agora as 'just' another project -
it could have a million connection pools if it wanted - the committers
from other projects would have no right to interfere - if they want to
participate, they have to participate :)
> And I do disagree - you are better of having to choose between different
> implementations than by having a "right and perfect" project. Not only
> choice is good, but it also reduce the tensions among people and results
> in a healty community - most of the flames and tensions I saw so far were
> a direct result of people arguing they have the "right and
> perfect" solution ( in other words - intolerance to others ).
I disagree with your interpretation. Choice is good. Pointless
duplication isn't. I think that if there is a project <FOO> and someone
wants to add something new, great. If the community surrounding <FOO>
doesn't want that, then by all means start a new project. But really -
it should be something different, or new, or something that adds value,
something rational. Multiple implementations of the same identical
thing is a waste of talent and time.
>
> But again, we have to agree to disagree.
>
> ( I lived in a system with a single party and a single "right" way )
>
>
>
> > And for that matter, why stop there? See if you can get tomcat bundlded
> > into j2ee.jar :)
>
> It is already ( not only j2ee - but AFAIK enchydra and ejboss - 2 other
> implementations of the same APIs :-)
At last check, tomcat isn't in j2ee.jar
>
> > > 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.
> >
> > No. This is the wierd model I didn't vote for - I think that the
> > library committers agree that the DBCP project is needed, and the people
> > proposing it are earnest in intent, have the skills to make pulling it
> > off a possiblity, etc. Then, it's free from the control of the library
> > committers as a group, and control belongs to the committers of that
> > project, modulo remaining true to the charter of their project and
> > Jakarta. (Hopefully lots of the library committers would want to join
> > and help, but we all are busy and time is scarce.)
>
> I can't stop you - as long as DBCP will not claim to be the "only" way.
It's not a matter of stopping me. If we don't figure this out, we are
going to propose a project that we all aren't comfortable with, or we
don't propose, and spend another 2 weeks going in circles...
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
