[EMAIL PROTECTED] wrote:
>
> > We can have a separate CVS for multiple 'mini-projects', and one is for
> > Agora [ a big 'add-everyone-in-jakarta' free-for-all incubator], one for
> > Directory, and one is for the DBConnectionPool with it's committers, and
> > one for XML config, one for ...
> >
> > I just don't understand why it's all or nothing.
>
> It's not all or nothing - but creating a CVS tree for 5 classes is a bit
> too much. Most components will be reasonably small.
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.
It's a complete project.
If it didn't it would live in the incubator/Agora/playpen/crib whatever
you want to call it.
> If a component is very big we can discuss having a separate tree.
What does size have to do with it?
"My, your code is large." "Why thank you. That's my JUnit..."
No - It's a control and organizational mechanism...
> > Has it ever been a problem where someone with something to add to a
> > project wasn't able to participate?
>
> No, it's not about that - it's about the overhead of having to deal with
> multiple trees.
What overhead? Remembering what is where?
> 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...
Keeps the jar dependencies to a minimum if you only have one to specify
in the classpath.
;->
> > Why? Then the whole purpose of productized, independant components goes
> > out the window - it would be just like we have now - a seething mass of
> > stuff that no one can dig out and use independant of the owning project.
> > (Yes, a gross generalization, but right more often than not...)
>
> Or the reverse is true - we end up with a mass of CVS trees, each with 10
> files, some active and some not.
No. You may end up with a mess of CVS trees, but each contains a
separately buildable component with docs, etc. If developers don't care
about the project, if users aren't using it, then move to the Component
Happy Hunting Ground.
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.
And if it wasn't substantial enough to be a standalone component, it
wouldn't get a CVS tree of it's own in the first place.
> > Because taglibs is a set of related items. Whats related about a DB
> > Connection Pool and a Testing Suite?
>
> Both are part of the commons, general purpose software.
Isn't that kind of circular? What they have in common is that we are
talking about putting them into the same place?
I would argue Tomcat/Catalin and Struts/Taglibs are each closer to each
other than DBCP and a Test Suite...
> > Why don't you do it in the Tomcat project then? Version issue? :)
>
> 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?
:)
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
