[EMAIL PROTECTED] wrote:
> ( 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 :-)
We do it in velocity - we use junit, jdom, xerces and ant for various
parts of our build, regression/verification testing and documentation
processes, which are equally as important to a user as the code. (You
will pry JUnit from my cold dead hands.. :)
If you think we were going to ask them to get the sources for jdom, ant,
xerces, and jdom to build velocity, you're nuts... :)
I think that when you decide to use another piece of code as a
component, a building block if you will, you should treat it as such -
get the release jar, test it well, and include that in the package.
Don't make it 'Version Wack-a-Mole'. That just leads to pain all
around.
> 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 ).
And Catalina's build is downright painful (or was). Just throw into the
CVS tree the versions of regexp, oro, whatever that you know work and
are required. Please.
>
> 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.
Yep.
> ( 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 ).
But no distributable product :)
> > No - It's a control and organizational mechanism...
>
> Control and organization are not resolved by CVS trees :-)
Huh?
> > > 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.
Or just take the latest release version. Really - when I use something,
jdom, Oro, log4j, whatever, I am not really interested in getting last
nights snapshot.
I want a version that works, that I can use as a tool, and just get on
with whatever I was working on. When a new version is release by the
project, I get that if there was something new I care about.
> And BTW, what happens if multiple DBPools are created ? Or what happens
> with the (expected) inter-dependencies between components ?
Well, the DBPool project is currently listed as being somewhat generic,
including general pooling stuff.
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.
> 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 )
You just said CVS has nothing to do with organization :)
> ( 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 :-)
I am not running out of ideas - I am running out of energy :)
>
> > > 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 ?
Yes, but we still live in our own houses, and have our own jobs to do.
And for that matter, why stop there? See if you can get tomcat bundlded
into j2ee.jar :)
> > 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.
Fine - I didn't mean obliterate the bits - remove it from the list of
'active' library componenets (have a list of 'retired' ones....) This
can't be that insurmountable a problem...
>
> > > 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.
And?
> 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.)
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
