Stephen Colebourne <[EMAIL PROTECTED]> 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.
I simply don't see the point. It is like saying "I don't want to use
HashMap because it is not in JDK 1.2; I write my own class". The point
of having commons is, that we actually use that code. We are not just
showcasing this, we are eating our own dog food.
And with tools that might some day (maven 2) or today (ivy) able to
resolve transitive dependencies, I don't even see a reason not to
include external dependencies even in the commons.
And commons-email is not exactly an "everyday, let's throw this in our
application" component like c-l, c-c or commons-math.
>My -1 will change to -0 if there is no public API
>dependency on [lang] (as the dependency can then be
>removed in v1.1). Which means changing the superclass
>of EmailException, and following the pattern of
>[collections] FunctorException.
Give us a patch. Code before words. As I said, I've looked into this
and I might do some work for 1.1. Not for 1.0.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
