I suspect it was after the extended conversation about dumping mock in favor of always using MAC.
On Wed, Apr 23, 2014 at 11:28 AM, Keith Turner <ke...@deenlo.com> wrote: > On Wed, Apr 23, 2014 at 12:03 PM, Sean Busbey <bus...@cloudera.com> wrote: > > > The default japi configurations were set to ignore the mock package. > > > > > Oh, thats not good. I probably did that, but I do not remember why. > > > > > > > > On Wed, Apr 23, 2014 at 10:58 AM, Keith Turner <ke...@deenlo.com> wrote: > > > > > On Wed, Apr 23, 2014 at 10:47 AM, Sean Busbey <bus...@cloudera.com> > > wrote: > > > > > > > Okay, I think all of these incompatibilities are things that should > not > > > > have been in the public API in the first place. > > > > > > > > * client.admin.SecurityOperationsImpl > > > > * client.admin.TableOperationsImpl > > > > * client.admin.InstanceOparationsImpl > > > > * client.mock.MockShell > > > > * client.mock.MockTabletLocator > > > > > > > > These changes are due to refactorings outside of the public API > leaking > > > > into classes within the client that handle implementation. For these > > > > things, I think we should fix them to not be in the public API and > just > > > > include an apology in the release notes. > > > > > > > > > > > > > +1 > > > > > > I remember seeing the .*Impl classes and ignoring them because they > were > > > Impl, but I shouldn't have because they are not in an impl package. I > > > don't remember seeing anything about mock, I must have glossed over > that. > > > > > > > > > > > > > > Any objections before I make a ticket and put up a patch? Do we need > a > > > vote > > > > about breaking the API, or is calling out that we're going to do that > > in > > > > the RC vote sufficient? > > > > > > > > (the other findings appear to be the japi compliance checker not > > > > recognizing a method moving up a class hierarchy) > > > > > > > > > > > > > > > > On Wed, Apr 23, 2014 at 1:27 AM, Sean Busbey <bus...@cloudera.com> > > > wrote: > > > > > > > > > Here's the current reports, built with japi-compliance-checker > 1.3.6 > > > > > > > > > > http://people.apache.org/~busbey/compat_reports/accumulo/ > > > > > > > > > > executed with: > > > > > > > > > > for version in 1.5.0 1.5.1 1.5.2; do japi-compliance-checker > > > > > -skip-deprecated -old japi-accumulo-${version}.xml -new > > > > > japi-accumulo-1.6.xml -l accumulo; done > > > > > > > > > > with the config xmls like what's in the repo, but set to look in my > > > maven > > > > > repo and to not skip mock. > > > > > > > > > > I'll triage the 1.5.0 changes tomorrow > > > > > > > > > > > > > > > > > > > > On Tue, Apr 22, 2014 at 9:04 PM, Eric Newton < > eric.new...@gmail.com > > > > >wrote: > > > > > > > > > >> I believe Keith did a mechanical/manual analysis and brought back > a > > > > couple > > > > >> of methods/classes. > > > > >> > > > > >> -Eric > > > > >> > > > > >> > > > > >> On Tue, Apr 22, 2014 at 8:46 PM, Sean Busbey <bus...@cloudera.com > > > > > > wrote: > > > > >> > > > > >> > Has anyone done a compatibility check for the public API between > > > 1.5.x > > > > >> and > > > > >> > 1.6.0? > > > > >> > > > > > >> > While looking into ACCUMULO-2722 I noticed some changes that > might > > > be > > > > >> > problematic in client.mock and was wondering if anyone did a > > larger > > > > >> sweep > > > > >> > already. > > > > >> > > > > > >> > -- > > > > >> > Sean > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > > Sean > > > > > > > > > > > > > > > > > > > > > -- > > > > Sean > > > > > > > > > > > > > > > -- > > Sean > > > -- Sean
