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 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>> >
