Re: dependency hell

[Chris Brown <br...@reflexe.fr>]

Hello all,

Concerning the "dependency hell" thread (that I sort of started on
httpclient's list), I would favour an "all-in-one, large .jar" approach as
suggested by Eric Johnson, because it should keep all versions and internal
dependencies nicely in sync, even if it complicates the release cycle.  It'd
be nice to keep an option to build (from source, with
Ant/maven/<build-system-of-the-day>) independent components, rather than one
big component, for those that *really* need it.  For projects outside of the
"all-in-one" jar (say, commons-sql), this'd at least reduce significantly
the number of dependencies (and the associated synchronisation problems).

On a related point, any comments on the rationale behind so many Apache
projects seemingly "competing" with each other?  From a user perspective,
this is confusing and off-putting, from a developer perspective, it seems a
waste of resources (why re-invent the wheel with slight differences, instead
of making a better wheel?).  Here's some examples that, as a user, seem to
illustrate this point:

 - ant and maven
 - torque and commons-sql
 - oro and regexp
 - tapestry, turbine, etc.

Hope this is constructive,
Chris

PS: I'm not subscribed to commons-dev, I'm (exceptionnally) cross-posting as
suggested by Eric ; I probably won't receive any replies unless I'm CC'd.

----- Original Message ----- 
From: "Eric Johnson" <er...@tibco.com>
To: "Commons HttpClient Project" <co...@jakarta.apache.org>
Cc: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, June 25, 2003 3:38 PM
Subject: Re: [SURVEY] Commons-URI or not?


> It would seem that most if not all of the responses from the HttpClient
> crew responded only to the HttpClient list, and not to commons dev.  So
> I'm not sure that all that might need/want to see the entirely negative
> feedback have seen it.  I don't subscribe to commons-dev, so if this
> doesn't get through, would someone mind reposting it there?
>
> I too am against a separate URI commons package, at least for the moment.
>
> In any event, who else depends on a URI class?  At the moment, there are
> three obvious sources for URI type functionality that I am aware of:
> HttpClient, Slide, and JRE 1.4.  Slide, rather than using what is in
> HttpClient, is using its own, even though Slide includes HttpClient in
> its build dependencies.  Without anyone even sharing the code in the
> first place, it doesn't seem like a good candidate for a separate project.
>
> One of the negatives that others have mentioned on the HttpClient list
> is the growing dependency problem within the Apache projects,
> particularly with the myriad of dependencies on commons projects, and
> among the commons projects themselves.  Perhaps what we need to do is
> start clumping some of the commons projects together, as well as having
> the stand-alone pieces we have now.  A first cut at combining some of
> the commons projects into one giant JAR might include:
>
>     * beanutil
>     * cli
>     * codec
>     * collections
>     * dbcp
>     * fileupload
>     * httpclient
>     * lang
>     * logging
>     * net
>     * pool
>
> My criteria for the above list were three-fold - base requirement of JRE
> 1.2 or later, that the project should have an official blessed release,
> and that it shouldn't depend on any outside libraries - like an XML
> parser - at runtime.  And I'll admit that I'm fudging on HttpClient (and
> file upload) a little, in that I don't think anyone following HttpClient
> would want to include the 1.0 release, but I'm guessing that by the time
> such a project is agreed upon and pulled together, HttpClient 2.0 will
> be final....  At least here's to hoping.
>
> Anyway, to the extent that a separate URI package would make sense, if
> we had a model such as the above, where most people used the one giant
> JAR instead of the individual ones, the creation of a separate commons
> URI project would be largely one of focus and interest, rather than an
> additional dependency quagmire.
>
> -Eric Johnson
>
> 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
>
> Sung-Gu wrote:
>
> >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-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org