Aaron, you just touched on what is the usefulness of the commons. The idea is that the Tomcat team and other teams with _common_ use code can drop such _common_ use components here, and hence the _commons_ name.
Of course that dropping such components here also means making them usable without depending on the mother project. Have fun, Paulo > -----Original Message----- > From: Aaron Smuts [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 04, 2002 5:24 AM > To: 'Jakarta Commons Developers List' > Subject: RE: [Logging] [VOTE] Commons Logging 1.0 Release > > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
