commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collections] Size and scope issues
Date Mon, 03 May 2004 15:21:42 GMT
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" <robertburrelldonkin@blueyonder.co.uk>
> 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" <robertburrelldonkin@blueyonder.co.uk>
> >> 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message