commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: Lang dependency [VOTE] Release Commons Email 1.0
Date Sat, 03 Sep 2005 11:08:22 GMT
On Fri, 2005-09-02 at 12:40 +0000, Henning P. Schmiedehausen wrote:
> Stephen Colebourne <> writes:
> >> The dependency on commons-lang is IMHO not really a
> >> big issue. The jar
> >> has ~ 200k and we are talking about a component
> >> which is probably not
> >> used on J2ME. If 200k for a really useful library is
> >> a problem, then
> >> commons-email isn't probably the right tool either.
> >This is a belief that is correct in theory, yet proves
> >wrong in practice (based on user feedback). At some
> >point, I shall have to draw together all the URLs from
> >the net regarding inter-commons dependencies.
> >The two issues are jar-hell (where jar versions
> >required by two jars clash), and the forced jar effect
> >(where users resent having to pickup other jars to use
> >a library jar).
> I know everything about jar hell, using unreleased jar versions, maven
> SNAPSHOTs and build tools that suddently get redesigned while you are
> not looking. Trust me. I'm from Turbine. :-)
> I'd actually agree with you if it wasn't for commons-lang. To me,
> there are two commons libs which I would consider "ok" for another
> commons component to depend on them: commons-lang and
> commons-collections. Both are pretty stable, have no external
> dependencies themselves and they contain such a huge number of useful
> classes, that trying to replace these would IMHO lead to code
> duplication and code-rotting.
> Personally, I pretty much consider c-l and c-c part of the regular
> java toolbox. Trying to invent that code again and again makes IMHO no
> sense. We tried this over in Turbine land and I can only say I'm happy
> that we finally got rid of all that reinvented code and use the
> commons.

it's been great to see code factored into reusable libraries such as
lang and collections. 

however, the perspective of creating basic reusable libraries is very
different from the perspective of creating applications. over the years,
some pretty bitter lessons have been learnt about the difficulties that
arise from dependencies between basic libraries. i agree with stephen
that dependencies between commons libraries is now considered something
to be avoided whenever possible.

many middleware vendors now repackage the basic libraries they use. this
allows them to depend upon a single known version without risking
conflict with libraries used by applications.

so, i'd suggest that email adopts a solution along those lines. the
simplest and quickest approach would be to simply copy the necessary
source and repackage it as if people are
happy with this approach, i'd be willing to make the change.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message