commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [COLLECTIONS] 3.3 release
Date Wed, 06 May 2009 06:15:33 GMT
James Carman wrote at Mittwoch, 6. Mai 2009 03:12:

> On Tue, May 5, 2009 at 6:36 PM, Matt Benson <> wrote:
>> I feel differently--how many times do we need to duplicate code that does
>> the same damned thing amongst the various components?  For example, we've
>> now added MethodUtils to [lang], but [collections] has its own set of
>> code supporting InvokerTransformer.  [functor] doesn't have an analogous
>> function because it seemed to me silly to keep rewriting and/or copying
>> the necessary code.  IMHO we of the Commons need to establish an approach
>> for "mixin" components, optional dependencies, svn externals, something,
>> to avoid doing this again and again and again.
> I'm with Matt on this one.  I really hate that Collections has its own
> functors and I really hate having to copy code from one place to
> another all the time.
> I'd like to be able to keep my own little library of nifty functors
> and use those throughout my application in different contexts.  Right
> now, I have to use adapters all the time to go between one or the
> other (functors vs. collections).  Yuck!  I've even gone as far as
> creating little frameworky type classes that take these functor
> classes (TransformerListCellRenderer and TransformerTreeCellRenderer
> come to mind).
> Perhaps we could split functors into an API jar and a utils or
> algorithms jar?  The API would have all the main interfaces in it (the
> stuff in org.apache.commons.functor).  Collections could depend on the
> API and if folks want to use stuff from functor to do what they want,
> then so be it.  If not, oh well.  The API itself really can't evolve
> that much.  Those interfaces have been the same for a long time (other
> than the generics)

Maybe it's also time to think about more fine grained artifacts. With Maven
the dependency management is no longer that worse. We could have


with the latter providing the stuff of collections depending on functor.
This will not work for all kind dependencies between the commons stuff
(e.g. helper classes from commons-io), but there are some components now,
where an currently optional dep simply means additional functionality (e.g.
in configuration or vfs).


- Jörg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message