accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [VOTE] Deprecate mock in 1.6.0
Date Wed, 20 Nov 2013 05:13:59 GMT
I think I may have convinced myself otherwise talking to Billie today.

MockAccumulo has been the way it is for some time now (two, going on 
three, major releases). We know it's not ideal and has internal 
limitations. It doesn't make sense to me to devote more time into it 
knowing that. For the same reasons, it doesn't make sense for us to 
spend time moving it for the sake of moving it, because at the end of 
the day, it's still the same code it was before.

0 to deprecate under the notion that we have other stuff that we can 
work on that's likely more pressing. I'd say -1, but if someone feels 
that it is worth the effort, I'm not one to tell them not to do it.

Fix MockAccumulo to "throw new NotImplementedExceptions()" where 
necessary for API additions (if it doesn't already).

Strong +1 to seriously look into trying to speeding up MAC, creating an 
iterator test-harness and other testing tools in the 1.7.0 time frame.

On 11/19/13, 1:22 PM, Bill Havanki wrote:
> A compromise would be to move MockAccumulo to its own subproject, and
> deprecate the copy resident in the public API. Then, it can start to drift
> toward a side project that those interested in maintaining can work with,
> but that does not need to be kept in lockstep with the arrival of new
> features.
>
> The side project never needs to be deprecated, but the core project has the
> option to migrate away from it over time. Users can switch over to it if
> they want to continue using it.
>
> Bill
>
>
> On Mon, Nov 18, 2013 at 5:45 PM, Christopher <ctubbsii@apache.org> wrote:
>
>> Ugh. Okay. I hadn't realized this.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Mon, Nov 18, 2013 at 5:33 PM, Sean Busbey <busbey+ml@clouderagovt.com>
>> wrote:
>>> On Mon, Nov 18, 2013 at 4:26 PM, Christopher <ctubbsii@apache.org>
>> wrote:
>>>
>>>> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <josh.elser@gmail.com>
>> wrote:
>>>>
>>>>> Is this just my interpretation of how to interpret @Deprecated? It
>> seems
>>>>> completely logical to deprecate something we know isn't where we want
>> to
>>>> go
>>>>> even if we aren't to where we want to go. Then, we start focusing on
>>>>> making/improving the tools we want. This advertises to users that
>> maybe
>>>> they
>>>>> might not want to rely on MockAccumulo.
>>>>
>>>> I agree.
>>>>
>>>> And, I don't think Joey's point about the M/R API in Hadoop applies
>>>> here. MockAccumulo was never part of our "public API". It's
>>>> developer-facing and intended for testing... not core to working with
>>>> Accumulo.
>>>>
>>>>
>>> Mock most definitely is a part of our public api for 1.4.x and 1.5.x.
>> Both
>>> READMEs basically say the same:
>>>
>>>
>>> 9. API
>>>
>>> The public accumulo API is composed of :
>>>
>>>   * everything under org.apache.accumulo.core.client, excluding impl
>> packages
>>>   * Key, Mutation, Value, and Range  in org.apache.accumulo.core.data.
>>>   * org.apache.accumulo.server.mini
>>>
>>> To get started using accumulo review the example and the javadoc for the
>>> packages and classes mentioned above.
>>>
>>>
>>> Mock is in org.apache.accumulo.core.client.mock which means it's a part
>> of
>>> the public API.
>>>
>>>
>>> --
>>> Sean
>>
>
>
>

Mime
View raw message