I am not in favor of a core jar but I would like to note that "including" components into "your" jar is not unprecedented. If you look at Xalan, it includes all sorts of components in its jar.
Gary > -----Original Message----- > From: Henri Yandell [mailto:[EMAIL PROTECTED] > Sent: Monday, August 18, 2003 21:54 > To: Jakarta Commons Developers List > Subject: Re: [combo] Commons Core release? > > > > 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]
