> It's not just a place for classes. How come we can't connect on this
> point? A component would have a clear purpose, have documentation, have
> a build script, etc... it's not SourceForge.
Each project at SourceForge has a clear purpose, (some) documentation,
build script and a CVS tree.
Creating CVS trees for each component is not that hard - but I would argue
that using multiple components will be hard.
My experience so far ( with jakarta-tomcat, which depends on
jakarta-tools, jakarta-servletapi, jakarta-watchdog ) is that the more CVS
trees you have, the harder it is for users and the bigger the temptation
of checking in binaries.
( I am on the same page with Sam here, I don't like binaries in the CVS
tree - even if I did checked in few :-)
For tomcat users ( who choose to build from the sources) this has been
probably the most confusing thing - that they need 3-4 different CVS
trees. ( not to mention that if we go this way, the CVS trees might vary
as tomcat uses one or other components ).
I guess this discussion is as pointless as the one about name - it's a
matter of taste and arguments don't help too much.
( plus - I'm running out of arguments - all I have is my personal taste
and a slight feeling that by sharing a CVS we might have more synergy
between components and developers - maybe more uniformity in code
conventions, etc ).
> No - It's a control and organizational mechanism...
Control and organization are not resolved by CVS trees :-)
> > No, it's not about that - it's about the overhead of having to deal with
> > multiple trees.
>
> What overhead? Remembering what is where?
And remembering what components do you need to check out today.
Remember, we want projects to gradually move to the common components - so
every week users will have to check out another CVS tree.
And BTW, what happens if multiple DBPools are created ? Or what happens
with the (expected) inter-dependencies between components ?
Yes, we want to minimize that, but in reality it's not easy - it's a
gradual process.
( that would be an excelent argument for your side, BTW - that separate
CVS trees will force better separation )
( and another argument, in case you run out of ideas, is that separate CVS
trees will make it easier to tag workspaces and easier to work with the
CVS :-)
> > The ideal solution for me would be to have only 2 trees to worry about -
> > the library CVS and tomcat CVS.
>
> Why deal with all that overhead? Just make one huge Jakarta tree, grant
> everyone write access, and get this over with...
I would love to :-) We are one big, happy community or not ?
> I don't mean that this will be a CVS-o-Matic or SourceForge or... If a
> component isn't used anymore, supported anymore, whatever, remove it.
Ops, then what happens with the projects that used it once ? I expect to
be able to build any version of tomcat at any time - no history can be
removed, that's the purpose of CVS !!. You can't just remove a CVS tree,
if it was used once in a project and you want to be able to re-create the
build ( needed for many reasons ) - you need to keep all ( tagged ) trees
around.
> > I'm trying to - but it's taking time. Catalina started this way, and I
> > can see the benefits. Same for taglibs.
>
> 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.
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.
Costin
