On Fri, 2005-09-02 at 12:40 +0000, Henning P. Schmiedehausen wrote: > 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.
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 org.apache.commons.email.lang. if people are happy with this approach, i'd be willing to make the change. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
