hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Brown" <bro...@reflexe.fr>
Subject Re: [SURVEY] Commons-URI or not?
Date Wed, 25 Jun 2003 07:27:01 GMT

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

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

- Chris

----- Original Message ----- 
From: "Sung-Gu" <jericho@apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>;
"Commons HttpClient Project" <commons-httpclient-dev@jakarta.apache.org>
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:
> For additional commands, e-mail:

View raw message