On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote: > Originally [reflect] was proposed for low-level reflection helpers. > However this got changed to [lang] because:
Not "proposed", suggested, both in the [reflect] and [lang] case. > - the package would consist of only 4 classes What's the threshold number of classes a component needs before it can be accepted as a commons component? > - it would still need to depend on [lang] > - [beanutils] would thus have to depend on [reflect] and [lang] Why would this be true? beanutils (which is where we moving a number of these classes from) doesn't depend on lang for example. What feature of [lang] is strictly necessary for reflection? Even if this were true, what difference does that make? [dbcp] depends upon [pool], but that doesn't justify making dbcp a part of pool. [digester] depends upon [beanutils], but that doesn't justify making digester a part of beanutils. > People seem to be loathe to include anything as a dependency in commons. s/loathe to include/careful about adding > This issue is all about dependencies and who does what. Commons could > create 20 tiny jars easily, or it could create one [core] jar. Which is > the right approach???? It was the first question I raised on joining, > and we're still arguing about it. The charter seems pretty clear to me on this: "2. The package library is not a framework but a collection of components designed to be used independently." "3. Each package must have a clearly defined purpose, scope, and API -- Do one thing well, and keep your contracts." I'm also not sure this is really a mutually exclusive decision. If we want to create a [core] jar, we certainly could do so (e.g., http://cvs.apache.org/viewcvs/jakarta-commons/combo/). By the charter guidelines, it should be possible to distribute a single component in isolation, but that doesn't prohbit creating whatever bundles you'd like to create. - R. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
