James Carman wrote at Mittwoch, 6. Mai 2009 03:12: > On Tue, May 5, 2009 at 6:36 PM, Matt Benson <gudnabr...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
