That was my interpretation as well.
On Fri, Mar 28, 2014 at 3:13 PM, Mike Drob <[email protected]> wrote: > Public members, including inner classes, of public classes seem like they > are de facto Public API. > > > On Fri, Mar 28, 2014 at 3:11 PM, Josh Elser <[email protected]> wrote: > > > Yes. This is exactly what was discussed earlier in this thread. > > On Mar 28, 2014 10:35 AM, "Christopher" <[email protected]> wrote: > > > > > That README was probably written without consideration of the > > > implication for inner-classes. There is a strict interpretation, yes, > > > but the intent is certainly not clear. > > > > > > -- > > > Christopher L Tubbs II > > > http://gravatar.com/ctubbsii > > > > > > > > > On Fri, Mar 28, 2014 at 1:12 PM, Sean Busbey < > [email protected]> > > > wrote: > > > > The README is already clear that everything under those packages is > > > > included, with the exception of the impl pacakge. > > > > > > > > In my reading, that means all Classes and Interfaces in any package > > under > > > > the client package, and everything in those classes that is at either > > > > public and protected access. > > > > > > > > I guess this should be included in our pending discussion about > > > > compatibility across versions? > > > > > > > > > > > > On Fri, Mar 28, 2014 at 12:02 PM, Josh Elser <[email protected]> > > > wrote: > > > > > > > >> Also, reading back through this chain, it was state as unclear as to > > > >> whether or not an inner class of a class in the public API is also, > > > itself, > > > >> in the public API. > > > >> > > > >> This should also be clarified in our definition of public API in the > > > >> README. Obviously, Don and Sean both agree that it should be. The > > > >> discussion of those on the vote didn't. Doesn't really matter to me > > > either > > > >> way. > > > >> > > > >> > > > >> On 3/28/14, 9:50 AM, Josh Elser wrote: > > > >> > > > >>> Ah, I missed the recursiveness of the o.a.a.c.c. > > > >>> > > > >>> But, like I mentioned in the other message, I don't think binary > > compat > > > >>> was achieved, but the package name, constructors, and methods > > existing > > > >>> in 1.5.0 were maintained AFAIK. Are we asserting binary compat here > > as > > > >>> well? > > > >>> > > > >>> I'm trying to understand if we actually didn't follow our own > rules, > > or > > > >>> if the expectations of the community are exceeding the rules we > have > > > for > > > >>> ourselves. I think we're in the latter right now. > > > >>> > > > >>> On 3/28/14, 9:41 AM, Sean Busbey wrote: > > > >>> > > > >>>> According to the definition of the public API in version 1.5.0, > > > >>>> RangeInputSplit is a part of the public API. > > > >>>> > > > >>>> > > > >>>> On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser < > [email protected]> > > > >>>> wrote: > > > >>>> > > > >>>> Devil's advocate: RangeInputSplit isn't part of the public API > > > >>>>> either, so > > > >>>>> it comes with the same risks that TabletLocator would. > > > >>>>> > > > >>>>> It sounds more like the definition of "public api" should be > > > expanded to > > > >>>>> prevent this in future cases. I need to look at what exactly > broke > > > >>>>> for Don. > > > >>>>> > > > >>>>> > > > >>>>> On 3/28/14, 9:12 AM, Sean Busbey wrote: > > > >>>>> > > > >>>>> Don, > > > >>>>>> > > > >>>>>> If you can file a jira with some example code that covers what > > > parts of > > > >>>>>> the > > > >>>>>> 1.5.0 API you hit, I can see if I can a patch to get you > working. > > > >>>>>> > > > >>>>>> That would give you a patch you could apply on top of 1.5.1 now > > and > > > >>>>>> when > > > >>>>>> 1.5.2 comes out it would correctly support the API. > > > >>>>>> > > > >>>>>> -Sean > > > >>>>>> > > > >>>>>> On Fri, Mar 28, 2014 at 8:49 AM, Donald Miner < > > > [email protected] > > > >>>>>> > > > >>>>>>> wrote: > > > >>>>>>> > > > >>>>>> > > > >>>>>> I'm starting to dig around for a workaround and figured > someone > > > >>>>>> might be > > > >>>>>> > > > >>>>>>> able to help me right away. > > > >>>>>>> > > > >>>>>>> In digging deeper, we were using RangeInputSplit because it > gave > > us > > > >>>>>>> the > > > >>>>>>> splits AND the locations. We use the locations for some data > > > locality > > > >>>>>>> placing in our distributed application. listSplits only gives > us > > > >>>>>>> splits. > > > >>>>>>> > > > >>>>>>> Is there an easy way to get both of these pieces of information > > > >>>>>>> together? > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> On Thu, Mar 27, 2014 at 3:28 PM, Josh Elser < > > [email protected]> > > > >>>>>>> wrote: > > > >>>>>>> > > > >>>>>>> Ack, sorry about that, Don. > > > >>>>>>> > > > >>>>>>>> > > > >>>>>>>> We probably should have been more strict about that. It's > tough > > to > > > >>>>>>>> make > > > >>>>>>>> a > > > >>>>>>>> call about a public class that someone *might* be using. > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> On 3/27/14, 12:26 PM, Donald Miner wrote: > > > >>>>>>>> > > > >>>>>>>> Sorry to necro this thread, just wanted to throw my 2 cents > > in. > > > >>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> We had some user code referencing this code directly and our > > > >>>>>>>>> application > > > >>>>>>>>> no > > > >>>>>>>>> longer works in 1.5.1. Just found out today when installing > on > > > >>>>>>>>> 1.5.1. > > > >>>>>>>>> In > > > >>>>>>>>> retrospect, we should have been using .listSplits from > > > >>>>>>>>> TableOperatons, > > > >>>>>>>>> > > > >>>>>>>>> but > > > >>>>>>>> > > > >>>>>>> > > > >>>>>>> instead we were using the RangeInputSplit method to get the > > splits > > > >>>>>>>> for a > > > >>>>>>>> > > > >>>>>>>>> table. > > > >>>>>>>>> > > > >>>>>>>>> I guess since we probably shouldn't have been doing that, I > > don't > > > >>>>>>>>> know > > > >>>>>>>>> > > > >>>>>>>>> if > > > >>>>>>>> > > > >>>>>>> > > > >>>>>>> that's a case for this not being deleted without going to > > > >>>>>>>> deprecated... > > > >>>>>>>> > > > >>>>>>>>> but > > > >>>>>>>>> we did have a nasty surprise and a deprecation warning would > > have > > > >>>>>>>>> been > > > >>>>>>>>> nice. > > > >>>>>>>>> > > > >>>>>>>>> -d > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> On Tue, Feb 25, 2014 at 11:33 PM, Adam Fuchs < > > [email protected]> > > > >>>>>>>>> wrote: > > > >>>>>>>>> > > > >>>>>>>>> I'll buy that the RangeInputSplit is probably not > referenced > > > >>>>>>>>> directly > > > >>>>>>>>> > > > >>>>>>>>> in > > > >>>>>>>> > > > >>>>>>> > > > >>>>>>> user code. In this case it's probably not a big enough change > to > > > >>>>>>>> delay > > > >>>>>>>> > > > >>>>>>>>> the > > > >>>>>>>>>> release. > > > >>>>>>>>>> > > > >>>>>>>>>> Adam > > > >>>>>>>>>> On Feb 25, 2014 6:19 PM, "Christopher" < > > [email protected] > > > > > > > >>>>>>>>>> wrote: > > > >>>>>>>>>> > > > >>>>>>>>>> I don't know that this inner class used for M/R should be > > > >>>>>>>>>> considered > > > >>>>>>>>>> > > > >>>>>>>>>> public API... nor do I imagine it will cause compatibility > > > >>>>>>>>>>> problems > > > >>>>>>>>>>> if > > > >>>>>>>>>>> users aren't referencing it in their code (which there's no > > > >>>>>>>>>>> reason to > > > >>>>>>>>>>> expect them to). I don't know if anybody is subclassing > > > >>>>>>>>>>> RangeInputSplit, but I'd suspect that it's an acceptable > > risk. > > > >>>>>>>>>>> Re-adding an inner class that subclasses the now external > one > > > >>>>>>>>>>> may be > > > >>>>>>>>>>> a > > > >>>>>>>>>>> good workaround. I don't think this would require > > recompilation > > > >>>>>>>>>>> for > > > >>>>>>>>>>> runtime compatibility, but if it does, I think that's > > probably > > > >>>>>>>>>>> acceptable. > > > >>>>>>>>>>> > > > >>>>>>>>>>> -- > > > >>>>>>>>>>> Christopher L Tubbs II > > > >>>>>>>>>>> http://gravatar.com/ctubbsii > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> On Tue, Feb 25, 2014 at 6:13 PM, Josh Elser < > > > [email protected] > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > >>>>>>>>>>> wrote: > > > >>>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> I haven't checked what would happen. If you subclassed the > > > >>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>>> RangeInputSplit, > > > >>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> it's rather likely that you'd need a recompilation. > > > >>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> On 2/25/14, 5:59 PM, John Vines wrote: > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> Will it? Clients don't interact with that code at all > > > directly. > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> On Tue, Feb 25, 2014 at 5:57 PM, Adam Fuchs < > > > [email protected]> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> wrote: > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>> Thanks for running that checker, Keith. Should we not > be > > > >>>>>>>>>>> worried > > > >>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>>> about > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>> the > > > >>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> removal of InputFormatBase.RangeInputSplit? If I read > > > correctly > > > >>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>>> this > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>> > > > >>>>>>>> will > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>> break both binary (runtime) compatibility and code > > > >>>>>>>>>>> (compile-time) > > > >>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> compatibility. Can somebody make an argument for why this > > is > > > >>>>>>>>>>>>> not a > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>>> problem > > > >>>>>>>>>>>>>> in a minor release with no previous deprecation? > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> Is there a quick way to fix this, like by subclassing > the > > > >>>>>>>>>>>>>> org.apache.accumulo.core.client.mapred.RangeInputSplit > in > > a > > > >>>>>>>>>>>>>> o.a.a.c.c.mapred.InputFormatBase.RangeInputSplit that we > > > >>>>>>>>>>>>>> mark as > > > >>>>>>>>>>>>>> deprecated? > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> Adam > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> On Tue, Feb 25, 2014 at 5:17 PM, Keith Turner > > > >>>>>>>>>>>>>> <[email protected]> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> wrote: > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>> I ran a utility [1] to analyze API diffs [2] between > > 1.5.0 > > > >>>>>>>>>>>> and > > > >>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>>> 1.5.1-RC3. > > > >>>>>>>>>>>>>>> The configs I used are the two xml files in the parent > > [3] > > > >>>>>>>>>>>>>>> of the > > > >>>>>>>>>>>>>>> report. > > > >>>>>>>>>>>>>>> I think the diff looks ok. I used jars from 1.5.0 and > > > >>>>>>>>>>>>>>> 1.5.1-RC3 > > > >>>>>>>>>>>>>>> bin.tar.gz. > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> [1] : > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > http://ispras.linuxbase.org/index.php/Java_API_Compliance_ > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> Checker > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>> [2] : > > > >>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>>> > http://people.apache.org/~kturner/1.5.0_to_1.5.1-RC3/ > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> compat_report.html > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>> [3] : > > > http://people.apache.org/~kturner/1.5.0_to_1.5.1-RC3/ > > > >>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser < > > > >>>>>>>>>>>>>>> [email protected] > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>> > > > >>>>>>>>>>>>>>> wrote: > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> All, > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> Please consider the following candidate as Apache > > Accumulo > > > >>>>>>>>>>>>>>>> 1.5.1 > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> -- > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>> > > > >>>>>>>> now > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> with 100% more CHANGES changes. > > > >>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>>> Git artifacts: The staging repository was built from the > > tag > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> "1.5.1-rc3" > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> (3478f71a). > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> Maven Staging Repo: > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > https://repository.apache.org/content/repositories/ > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> orgapacheaccumulo-1002 > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> Source tarball: > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> http://repository.apache.org/content/repositories/ > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>> orgapacheaccumulo-1002/org/apache/accumulo/accumulo/1.5. > > > >>>>>>>> > > > >>>>>>>>> 1/accumulo-1.5.1-src.tar.gz > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> Binary tarball: > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> http://repository.apache.org/content/repositories/ > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>> orgapacheaccumulo-1002/org/apache/accumulo/accumulo/1.5. > > > >>>>>>>> > > > >>>>>>>>> 1/accumulo-1.5.1-bin.tar.gz > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> Changes since 1.5.1-RC2: ACCUMULO-2324, ACCUMULO-2361, > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> ACCUMULO-2369, > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> ACCUMULO-2378, ACCUMULO-2379, ACCUMULO-2380, > > > >>>>>>>>>> ACCUMULO-2385, > > > >>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> ACCUMULO-2387, > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> ACCUMULO-2390 > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> Keys: http://www.apache.org/dist/accumulo/KEYS > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> Final CHANGES: > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a= > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > blob_plain;f=CHANGES;hb=3478f71ae888f8d73aaa93837319a6 > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> dbb4ba0c8a > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> Testing: Unit test and auto-tests passed successfully. > > > Ran a > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> short > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>> > > > >>>>>>>> > > > >>>>>>>>>>>>>>>> (~2hrs) > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> CI on 6 node installation. Ran a brief (~1hr) CI test > on > > > one > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> machine > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>> with > > > >>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> the newly-released Hadoop-2.3.0. Built from src > > tarball, > > > and > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> verified > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> functionality with bin tarball. > > > >>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>>> Since there are very minor changes compared to 1.5.1-RC2, > > > >>>>>>>>>>>>>>>> this > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> vote > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>> > > > >>>>>>>> > > > >>>>>>>>>>>>>>>> will > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> be open for the next 72 hours (2/28/2014 0100 UTC). > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> Upon successful completion of this vote, a 1.5.1 > > > >>>>>>>>>>>>>>>> gpg-signed Git > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> tag > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>> > > > >>>>>>>> > > > >>>>>>>>>>>>>>>> will > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> be created from 3478f71a and the above staging > > repository > > > >>>>>>>>>>>>>>> will > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> be > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> promoted. > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> - Josh > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>> -- > > > >>>>>>> > > > >>>>>>> Donald Miner > > > >>>>>>> Chief Technology Officer > > > >>>>>>> ClearEdge IT Solutions, LLC > > > >>>>>>> Cell: 443 799 7807 > > > >>>>>>> www.clearedgeit.com > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>> > > > > > > -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
