commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: Lang dependency [VOTE] Release Commons Email 1.0
Date Fri, 02 Sep 2005 12:22:09 GMT
--- "Henning P. Schmiedehausen" <hps@intermeta.de>
wrote:
> Stephen Colebourne <scolebourne@btopenworld.com>
> writes:
> Could you now please either supply strong facts (I
> do agree up to some
> point with you on the lang issue and I'm currently
> looking into
> it. But I see no way that we do any changes for the
> 1.0 release) or
> leave it.

I am asking for the exception to be changed with my
-1.

I am requesting the dependency to be removed because
it is essentially unecessary, and will damage the
reputation of [email] and commons by its presence.
However I recognise that the removal of the dependency
is more of a decision for the email committers.


> You had seven release candidates time to
> raise your
> concerns. Doing it on the vote isn't exactly nice.

I understand your fustration. We all have time
constraints. Part of my role as a commons committer
(and not an email committer) is to object to mistakes
that will bite commons as a whole, eg. via loss of
reputation. This is particularly important for a first
release.


> 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).


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.

Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message