It isn't clear to me what problem you are trying to solve. No question I agree with the goal of having projects become more self sufficient... the things I worry about (based on actual, real world usage of this for quite some time now):
1) Containers like jakarta-commons-sandbox and xalan. Single checkout, multiple builds. 2) Staged builds like ant and xalan. Single checkout, multiple builds. 3) Redundancy. There are a lot of jakarta projects, but only one anoncvs password. Organizing information is always about tradeoffs. At the moment, having cactus referring to the jakarta repository definition allows me to checkout cactus using the anoncvs password on most machines, but with my rubys id on my machine. Having cactus assume that there is a repository definition somewhere for "jakarta" does make it less self contained, but also simpler and easier to maintain. As I said, tradeoffs. I like to deal in specifics, so the question in my mind is whether or not projects like cactus have to rely on an external definition for the jakarta repository is an unreasonable burden and whether or not the added flexibility is worth this burden. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
