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 <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?
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.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
