There's no good way to use Guava to replace the existing code from olamy inside of CollectionUtils.
The situation is this: Existing code makes plain java.util.Collections objects, and uses CollectionUtils to perform some multi-set-ish operations on them. Hopeful future code would use Guava multi-collection objects, and just use their native methods for mult-set-is operations. Guava doesn't have a superior mechanism for starting with plain collections and doing this stuff. On Sun, Jun 12, 2011 at 4:12 PM, Stephen Connolly <[email protected]> wrote: > I'm more saying if you want to use guava as the back end for the new impl, > > On 12 June 2011 21:11, Benson Margulies <[email protected]> wrote: >> 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] >> >> > > --------------------------------------------------------------------- > 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]
