commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <>
Subject Re: [combo] Commons Core release?
Date Fri, 15 Aug 2003 23:24:52 GMT
On Thu, 14 Aug 2003, Henri Yandell wrote:

> Forcing a user of three api's to grab
> dependencies for 12 other api's is going to kill combo dead in the water.

An observation: a user of 3 APIs doesn't need to grab any external
dependencies outside of those three APIs. If you never load or use the
dependent classes, you never need to load their dependencies.

For example:

> Commons-Logging:  log4j. logkit. avalon-framework.

Commons-Logging runs just fine without log4j, logkit, or avalon-framework.
Compiling Commons-Logging without these things is a different matter, of


> it would not contain HttpClient (?) which I
> thought might be 1.4 dependent now for SSL and would not include BeanUtils
> with the current api munging.

If you're not using HTTPS support within HttpClient, you don't
need to have the SSL libraries (which weren't 1.4 dependent when I last
checked) around either.

Including a component (such as Latka or Jelly, for example) with
dependencies on a large number of external JARs would not require all
users of commons-combo to grab those external JARs. (Of course, neither
Latka nor Jelly has 1.0 release IIRC, so they probably wouldn't be
included anyway.)

> > > I'm doing some trickery to turn BeanUtils' commons-logging dependency into
> > > a JDK1.4 util.logging dependency. It would be nice to add Pool, HttpClient
> > > and maybe Net [with some regexp trickery] and consider that a version 1.0.
> > >
> >
> > We can talk about that on a [beanutils] specific thread, but I'd be -1 on
> > doing this to the real BeanUtils code.  A very large number of BeanUtils
> > users do not have the luxury to run on a 1.4 JDK.
> Yeah, I've no desire to apply this to the BeanUtils code itself, and doing
> said munging concerns me that we might introduce bugs. However,
> commons-logging is not self-contained and therefore would invalidate
> commons-beanutils.

Creating a "comons-beanutils-for-commons-core.jar" that's different from
commons-beanutils.jar is an extremely bad idea IMO. This creates a much
worse problem than the one commons-core/commons-combo is trying to solve.

- Rod <>

View raw message