hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [SURVEY] Commons-URI or not?
Date Wed, 25 Jun 2003 09:24:35 GMT
Chris,

This problem is as old as software engineering itself. Code reuse
provides many benefits as well as many potential problems such as
versioning conflicts. In my opinion benefits still outweigh the
problems. Usually code reuse done right results in higher code quality,
provided that you get more people looking at it and stressing it in
different ways. This is exactly what URI code is in a dire need of.

We do plan to introduce other external dependencies in addition to
commons-logging, such as commons-codec. This said, we surely will not
let the number of external dependencies to get out of hands (Believe me,
there are several fine open-source products that I HATE simply because
of ridiculous number of dependencies: dom4j, werkflow, drools being one
of the most notorious). Any potential external dependency will be
subject to thorough analysis and discussion (or even voting) on this
mailing list. You can count on that.

Cheers

Oleg


On Wed, 2003-06-25 at 09:27, Chris Brown wrote:
> 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" <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:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> 


Mime
View raw message