As a user of jakarta projects I must say I agree with Chris on this one. No offense, but in the way I see it HttpClient isn't "big enough" to be splitted and to have one more dependency. I met the same trouble as Chris for commons-logging, helpfully most jakarta projects are willing to update to the latest when you ask, but sometimes it takes time.
Aurelien Chris Brown a écrit : > Please NO !!! > > We're now finding it very difficult to use a lot of Jakarta projects, > because of "dependency hell"... it's becoming worse than Microsoft's > famous "DLL hell" problem. The more self-contained you can keep an > API, the better ; yes, there are issues concerning code re-use, but > at present, we're having great difficulty using more than one Jakarta > project at a time in our projects. > > If you only use one Jakarta project at a time, you're generally ok. > > If you try to use more than one Jakarta project at the same time > within your own projects, you have to hope that no such library > relies upon any other commons component, because chances are that > they won't be expecting the same version of each library (they don't > always include the latest version of each "basic" API, and each > "main" Jakarta API has a different release cycle). Commons-logging > is generally included as standard. If each version of an API was > always backwards-compatible, maybe that'd work, but that's not always > pratical, realistic, or efficient. > > Or start hacking around with classloaders... and this too becomes a > futile exercise when you start deploying things on some versions of > Tomcat (for example) that "helpfully" expose common functionality, > using perhaps incompatible versions of APIs (usually from commons) > that are obsolete (or more recent than) the versions of these APIs > required by some other "empirical" Jakarta library. > > Some of the recent commons components, such as commons-sql, have a > ridiculous number of dependencies. > > One other observation about Commons projects (and > Jakarta/Apache in general) > ; although code re-use seems like a good idea, I'm now seeing several > different projects that aim to do more or less the same thing, such > as : > > - ant and maven > - torque and commons-sql > - oro and regexp > - tapestry, turbine, etc. > > Furthermore, if there's Log4J, why not just use it, instead of the > Commons-Logging layer? If a project goes JDK1.4+ -only after, then > migrate to java.util.logging ? > > On a personal note, I'm hoping that commons-net, which used to just > work "as-is", doesn't start depending on lots of different API > versions... > > I know this is the HttpClient list, and not some general Jakarta > list, but I sincerely hope that one of the few remaining Jakarta > projects that doesn't depend on many others doesn't go down the same > dependency nightmare route as many of the others, so I wanted to > illustrate *why* (as a user) I feel this way... > > - Chris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
