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 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. 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 <http://radio.weblogs.com/0122027/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
