commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
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 <gudnabrsam@yahoo.com> 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?

- Jörg


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


Mime
View raw message