accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: [DISCUSS] MiniAccumuloCluster goals and approach
Date Wed, 26 Mar 2014 15:54:13 GMT
On Wed, Mar 26, 2014 at 10:38 AM, Josh Elser <> wrote:

>> I suspect the choice to make MiniAccumuloCluster a class rather than an
>> interface with a factory was driven by the restrictions we put on API
>> changes between major versions and the fact that 1.5 had a class you could
>> instantiate via constructors[3].
> Ok, that makes the most sense to me - I hadn't previously considered the
> "deprecation" cycle since it previously wasn't held to that standard. I
> mocked up some changes to better match the rest of our "public API" objects
> (class, interfaces, factories). If we want to preserve this API
> compatibility from earlier versions, we *could* name the interfaces classes
> (what would normally be MiniAccumuloCluster and MiniAccumuloConfig) to
> something non-standard to support API compatibility (just requiring a
> re-compilation I think).
> I would be behind getting the interfaces how we want them long term before
> categorizing these classes as "public". I'm willing to make sure we're all
> happy with this for 1.6.0.
We already declared minicluster public in 1.5.0 and 1.5.1, so we're a bit
bound as is. We don't clarify in our docs if we maintain source
compatibility or binary compatibility.  I would caution that users tend to
presume both (and maybe binary a little more), based on the continued
dismay that happens around the Hadoop 1 -> Hadoop 2 Class/Interface stuff.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message