maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Anyone want to help?
Date Sun, 12 Jun 2011 20:16:51 GMT
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
<stephen.alan.connolly@gmail.com> 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 <bimargulies@gmail.com> 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
>> <stephen.alan.connolly@gmail.com> 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 <bimargulies@gmail.com> 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
>>>> <stephen.alan.connolly@gmail.com> 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: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

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


Mime
View raw message