It doesn't sound like there is a clear dependency chain among the projects.
In JCS I've had a hell of a time trying to use utilities from Tomcat, since they seem to move around. Maybe I just shouldn't have been using them. Outside of Jakarta this would be fine, since I can control the release version of 3rd party libraries, but inside it is more difficult. This is a difficult problem. You seem to have to stick to a project's high level API or intended usage. I can use Tomcat as a servlet engine, but not as a source of thread pool utility classes. When trying to use utilities, say the log4j configuration code or the Tomcat thread pool, you have to pretty much copy and modify the code (making appropriate citations to the source) and go on. I'm not sure how to solve this. In my own projects I define a dependency hierarchy and make sure that no one violates the chain. If commons becomes the base then it will probably end up bloating and being filled with redundant code and version with number in the names of classes . . . Every committer will need commons commit access so they can keep all their utilities that might be attractive to another project accessible and stable, or there will need to be a common acceptance to giving code a new home (my technique) to reduce the dependency complexity. For instance: JCS has a great indexed disk storage system, but I wouldn't try to use it outside of the JCS framework, since it is subject to change, but it has a much broader utility. Many of the log4j appenders are like this. In JCS I used some of the socket appender code for a TCP lateral cache. If they could be abstracted out into commons utilities they would be very useful, but this would require building with added flexibility and wrappers. . . . This is a tough problem. Cheers, Aaron -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
