OK, there are various cross package dependencies that have to be removed to make life simpler for separate jars.
1) ObjectGraphIterator depends on NOPTransformer - I've reworked it to remove the dependency 2) LazyMap depends on FactoryTransformer - This can only be reworked by copying FactoryTransformer as an inner class of LazyMap. This does seem a little crazy. 3) UniqueFilterIterator depends on UniquePredicate - Requires the inner class to be copied. 4) Typed* collections depend on InstanceofPredicate - I am planning on adding a new AbstractInputCheckingMapDecorator class which would help the map cases. It would allow the validation to occur without needing to create a predicate. Adding the new class also reduces overall jar size. Thus, we could then create jars for - Bag - BidiMap - Buffer - Comparator - Functor - Core (main/collection/set/list/map) Still not sure I really want to do this though :-( Stephen ----- Original Message ----- From: "robert burrell donkin" <[EMAIL PROTECTED]> > i definitely agree that one jar is the best solution for many users. > for those users for whom jar size is a big issue, then i'd say for that > for many use cases rolling a custom version (possibly repackaged) is > the best approach. (i have heard that this is how BEA re-uses the > commons logging stuff.) > > but we've been hearing that for some users - many of them influential > open source developers - this approach is unsatisfactory. one of the > main aims for jakarta commons was to facilitate re-use of library code > between open source projects. there are a few of ASF projects who are > refusing to use any jakarta commons components on principle now for > this reason. (they want small, tight libraries.) i suspect that this is > partly political but there is a kernel of truth in the criticisms. it's > best to think about this kind of issue early before a momentum > develops. > > certainly, i'm keen to see digester 2 (if and when it comes along) > factored into a small core with minimal dependencies together with > optional extensions. the binary distribution would contain both a > single complete jar and a set of multiple jars. i hope that this should > be able to satisfy most users and since this is just a build issue, i > suspect that the maintenance would be minimal. > > - robert > > On 3 May 2004, at 00:41, Stephen Colebourne wrote: > > > So what problem are we solving? Adding extra jar files alongside the > > complete built one creates classpath problems for users, an old > > version of > > the 'all' jar overriding a later version of the 'part' jar or vice > > versa. > > General chaos and confusion. > > > > People so have the ability to build their own jar files with just the > > classes they need. > > > > Oh, and I'd also suggest that more jar files does involve more work > > (maintaining and releasing), and there's a distinct lack of active > > committers on collections as it is ;-) > > > > Stephen > > > >> On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote: > >>> A neat ideal, but perceptions of "really common" versus "rarely used" > >>> seem to be awfully personal. Kinda reminds me of earlier commons-dev > >>> discussions trying to create a "commons core" JAR that included all > >>> of > >>> the "really common" commons JARs, and none of the others. Needless > >>> to > >>> say, there was no consensus on what the contents should be :-). > > > > From: "robert burrell donkin" <[EMAIL PROTECTED]> > >> i wonder whether it might be possible to separate out a core jar > >> containing just the basic interfaces and then split the > >> implementations > >> into several themed jars. i still think that this should be in > >> addition > >> to releasing a single jar containing everything, though. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
