commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [COLLECTIONS] 3.3 release
Date Thu, 07 May 2009 05:17:09 GMT

On May 5, 2009, at 11:15 PM, Jörg Schaible wrote:

> 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
>  collections-x.y.jar
>  collections-functor-x.y.jar
> 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).
> Opinions?

Well, it should be obvious that this seeming aversion to dependencies  
isn't something I consider part of a good design. I've added several  
to both configuration and vfs, all of which - as you pointed out - are  
optional. I really don't understand the benefit of having mulitple  
copies of code in various projects that will eventually get out of  
synch vs just sharing one copy. I thought that was what commons was  
supposed to be all about.

OTOH, commons components should be fairly small so the number of  
dependencies shouldn't get too out of hand.


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

View raw message