The static functions in CollectionUtils are substitutes for the Multi-collections in Guava. So, to substitute Guava, you have to rewrite the callers to actually use Multiset (or whatever) and not need these functions at all. That could get fiddly. So keeping this class in the bridge seems reasonable to me to give us more flexibility.
On Sun, Jun 12, 2011 at 4:07 PM, Stephen Connolly <[email protected]> wrote: > if guava is a better replacement and is ASL, i'm fine with it as a good fit > > On 12 June 2011 20:52, Benson Margulies <[email protected]> wrote: >> In the case of CollectionUtils, I don't see why we shouldn't keep the >> existing implementation. In most cases, it would be better to replace >> the use of this class with Guava, but, to the extent that we are using >> it, we're not going to find a better implementation in 'commons' that >> replaces Olivier's thing. >> >> On Tue, May 24, 2011 at 5:28 AM, Stephen Connolly >> <[email protected]> wrote: >>> I'm working on providing a compatibility layer for plexus-utils that >>> uses the commons-* stuff to provide the implementation. >>> >>> If anyone is interested in helping please shout out. >>> >>> Most of the work is actually writing the crazy test cases, everything >>> else should be simple shims through to existing commons functionality. >>> >>> You can join in here if you are an Apache Committer (sandbox is open >>> to all Apache Committers) >>> https://svn.apache.org/repos/asf/maven/sandbox/trunk/plexus-utils-commons-bridge >>> >>> Pick a plexus-utils class, and start creating tests... better still >>> write the tests black box (that's what I am doing!) >>> >>> Then when you have some tests written in the TCK module, create the >>> implementation class with all the methods: >>> >>> { throw new UnsupportedOperationException("Not implemented yet!"); } >>> >>> and then you can knock off implementations and see your test pass rate >>> rise in the bridge module. >>> >>> I'm tackling IOUtil first and then PropertyUtils. >>> >>> To stake your claim, commit the test case class first and then unless >>> you tell us otherwise you are working on that class! >>> >>> -Stephen >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
