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 ----- Original Message ----- From: "Sung-Gu" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Commons HttpClient Project" <[EMAIL PROTECTED]> Sent: Wednesday, June 25, 2003 7:09 AM Subject: [SURVEY] Commons-URI or not? > > Hi all, > > I suggest that jakarta-commons provides flexible URI issue implementations > as a package. > > Various applications using URI concept comes in the internet world. and > they need common mechanisms and algorithms for URI. > > For example, all internet programs will need fundamental functionalites of > URI like extensible parsing and manipulation container for URL reference, > URN and URC, escape codec mechanism, charset tranformation functionality, > URI transformation from real world identities or URN, or other > transformations related to DNS or telephony... If it would be prepared > commonly in Jakarta, we can save development powers. So I suggest new > commons-uri package. > > FYI, currently the commons-httpclient is using it. > > Any comments? > Or any +1, -1? > > Sung-Gu > > P.S.: If the requirement is very weak, I want to put the new package into > commons-sandbox even for a long while in my opinion... > > > ---------------------------------------------------------------------------- ---- > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
