commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [combo] Commons Core release?
Date Fri, 15 Aug 2003 23:31:02 GMT


On Fri, 15 Aug 2003, Rodney Waldhoff wrote:

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

It's very hard to know though. I look at the dependency list and it says
it needs 5 jars. We don't publish a 'you need this jar for this, this jar
for this' list. Also, who wants to trust that?

Only power users will be able to deal with this easily, and they have no
need for a combo jar.

> 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
> course.
>
> Similarly:
>
> > 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.

They come with 1.4 I believe.

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

Automating a build of this gets difficult I believe, plus you'd have to
not run certain tests. It feels like a rather manual solution.

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

Yeah. It should instead be commons-beanutils.jar which depends on
commons-logging-api.jar.

Hen


Mime
View raw message