On Sun, 17 Aug 2003, Rodney Waldhoff wrote:
> On Fri, 15 Aug 2003, Henri Yandell wrote: > > > 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. > > Not hard at all. Look for "NoClassDefFound". Not very good when I'm trying to learn about and install something. > > I look at the dependency list and it says > > it needs 5 jars. > > What dependency list? The compile-time ant and/or maven descriptors? We > don't have a formal or even conventional run-time dependency indication > AFAIK, although maybe this suggests we need one. Yep. Maven one. Some kind of runtime would be good. Just thinking about Commons Core/Combo is a good idea in terms of discovering problems here. Currently I'm building BeanUtils 1.6.1 into my jar [I like the javadoc on my PDA as one blob] but Math [which I'd like to start building in] relies on BeanUtils 1.5. As more cross-dependency is added, complexity will increase, with the possibility of a 'combo' being impossible due to cyclics etc. One solution to stop this is to stop dependencies in Commons between projects. Which is obviously painful, we can't eat our own dogfood because it might get tricky. If anything, a hierarchy diagram showing the dependencies would be a nice result from this. > > We don't publish a 'you need this jar for this, this jar > > for this' list. Also, who wants to trust that? > > Actually I believe in several places we do (e.g,. > <http://jakarta.apache.org/commons/logging/userguide.html>, > <http://jakarta.apache.org/commons/httpclient/sslguide.html>). The > STATUS files used to hold this information, probably many of > them have not been maintained. > > > 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. > > Both maven and gump seem to automate this rather well. I presume that they have the compile-time dependencies available at test-time. I would be aiming not to have things like log4j available, and yet this means I can't run the tests for commons-logging log4j component else it'll fall over. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
