Thanks for taking a look Ted! Looks like the second patch created with "git diff" excluded the Gradle wrapper JAR from the patch.
I would generate a new one which includes this this jar. In the meantime, you should be able to use the first patch attached to the JIRA which is in git-am format and that would let you build. On Fri, Jul 18, 2014 at 3:40 PM, Ted Yu <yuzhih...@gmail.com> wrote: > Nice work, Aditya. > > Looks like the hbase-native-client profile requires gradle ? > > [exec] Error: Could not find or load main class > org.gradle.wrapper.GradleWrapperMain > > Will take a look at your patch. > > Cheers > > > > On Fri, Jul 18, 2014 at 3:08 PM, Aditya <adityakish...@gmail.com> wrote: > >> As requested, I have attached a combined patch to the umbrella JIRA >> <https://issues.apache.org/jira/browse/HBASE-1015> and submitted it to >> >> jenkins. >> >> Would be great if someone could take a look and provide feedback. >> >> Regards, >> aditya... >> >> >> On Wed, Jul 9, 2014 at 7:05 PM, Aditya <adityakish...@gmail.com> wrote: >> >> > I was hoping to get some initial comments before attaching patches for >> the >> > build boat. >> > >> > I have broken the entire code into 5 patch sets, layered in a sequnce, >> > each focusing on a particular area (public headers/JNI >> > implementation/Examples+unit test, etc) for the ease of review. >> > >> > https://reviews.apache.org/r/23175/ >> > https://reviews.apache.org/r/23176/ >> > https://reviews.apache.org/r/23177/ >> > https://reviews.apache.org/r/23178/ >> > https://reviews.apache.org/r/23179/ >> > >> > These are also available as a sequence of patches as the pull request >> > <https://github.com/apache/hbase/pull/1>. >> >> > >> > Only the last patch hooks everything to the HBase build process >> > (optionally) and hence I was thinking of squashing these separate >> patches >> > into a single patch to be submitted for build. >> > >> > >> > On Wed, Jul 9, 2014 at 11:32 AM, Nick Dimiduk <ndimi...@gmail.com> >> wrote: >> > >> >> This ticket has only open subtasks, ie nothing in 'patch available'. I >> >> assume you mean HBASE-10168. We'll see about getting you some reviews, >> but >> >> you should also go about formatting the patch for buildbot. Also, since >> >> your 3 reviews are individually 100+k, you should consider breaking >> them >> >> into three separate tickets. >> >> >> >> my 2¢ >> >> -n >> >> >> >> >> >> On Mon, Jul 7, 2014 at 12:01 PM, Aditya <adityakish...@gmail.com> >> wrote: >> >> >> >>> Sorry about that. >> >>> >> >>> Here is the umbrella JIRA >> >>> https://issues.apache.org/jira/browse/HBASE-1015 >> >>> >> >>> >> >>> On Mon, Jul 7, 2014 at 10:05 AM, Nick Dimiduk <ndimi...@gmail.com> >> >>> wrote: >> >>> >> >>>> Would you mind including the JIRA numbers along with the request? >> >>>> >> >>>> Thanks, >> >>>> Nick >> >>>> >> >>>> >> >>>> On Mon, Jul 7, 2014 at 9:52 AM, Aditya <adityakish...@gmail.com> >> wrote: >> >>>> >> >>>>> Do we want to have the C APIs part of 1.0.0 release. I had posted >> few >> >>>>> patches and a set of review request sometime last week. >> >>>>> >> >>>>> >> >>>>> On Fri, Jul 4, 2014 at 1:21 AM, Enis Söztutar <enis....@gmail.com> >> >>>>> wrote: >> >>>>> >> >>>>> > On Thu, Jul 3, 2014 at 4:41 PM, Mikhail Antonov < >> >>>>> olorinb...@gmail.com> >> >>>>> > wrote: >> >>>>> > >> >>>>> > > Moved ZK watcher & listener subtask out of scope HBASE-10909. >> Enis >> >>>>> - with >> >>>>> > > that, I guess HBASE-10909 can be marked in branch-1? >> >>>>> > > >> >>>>> > >> >>>>> > Sounds good. >> >>>>> > >> >>>>> > >> >>>>> > > >> >>>>> > > HBASE-11464 - this is the jira where I'll capture tasks to >> >>>>> abstract hbase >> >>>>> > > client from ZK (mostly it would be post-1.0 work). >> >>>>> > > >> >>>>> > >> >>>>> > Not sure whether we can make it fully backwards compatible with >> 1.0 >> >>>>> > clients. I guess we will see when the patches are done. >> >>>>> > >> >>>>> > >> >>>>> > > >> >>>>> > > Thanks, >> >>>>> > > Mikhail >> >>>>> > > >> >>>>> > > >> >>>>> > > 2014-07-03 12:52 GMT-07:00 Stack <st...@duboce.net>: >> >>>>> > > >> >>>>> > > > On Thu, Jul 3, 2014 at 12:25 PM, Mikhail Antonov < >> >>>>> olorinb...@gmail.com >> >>>>> > > >> >>>>> > > > wrote: >> >>>>> > > > >> >>>>> > > > > Guys, >> >>>>> > > > > >> >>>>> > > > > getting back to ZK abstraction work w.r.t. release 1.0 and >> >>>>> > thereafter, >> >>>>> > > > some >> >>>>> > > > > status update. So as we're getting closer to complete >> >>>>> HBASE-10909, it >> >>>>> > > > looks >> >>>>> > > > > like the steps may be like this: >> >>>>> > > > > >> >>>>> > > > > - there are 2 subtasks out there not closed yet, one of >> which >> >>>>> is >> >>>>> > about >> >>>>> > > > log >> >>>>> > > > > splitting (and Sergey S has submitted a patch for review), >> >>>>> another is >> >>>>> > > > > abstraction of ZK watcher (this is what I've been working on >> >>>>> in the >> >>>>> > > > > background; but after sketching the patch it seems like >> >>>>> without being >> >>>>> > > > able >> >>>>> > > > > to modify the control flows and some changes in the module >> >>>>> structure, >> >>>>> > > > it'd >> >>>>> > > > > be a lot of scaffolding code not really simplifying current >> >>>>> code). So >> >>>>> > > I'd >> >>>>> > > > > propose to descope abstraction of ZK watcher jira >> >>>>> (HBASE-11073), >> >>>>> > > namely: >> >>>>> > > > > convert it to top-level JIRA and continue to work on it >> >>>>> separately; >> >>>>> > > > rename >> >>>>> > > > > HBASE-10909 to "ZK abstraction: phase 1", and mark it as >> >>>>> closed as >> >>>>> > soon >> >>>>> > > > as >> >>>>> > > > > log splitting jira is completed. This way HBASE-10909 fits >> to >> >>>>> > branch-1. >> >>>>> > > > > >> >>>>> > > > >> >>>>> > > > Sounds good to me. >> >>>>> > > > >> >>>>> > > > >> >>>>> > > > > - secondly, in the discussion to the CatalogTracker patch, >> we >> >>>>> > started >> >>>>> > > > > talking about modifying client to not know about ZK, but >> >>>>> rather keep >> >>>>> > > the >> >>>>> > > > > location of current masters and talk to them using RPC >> calls. >> >>>>> This >> >>>>> > work >> >>>>> > > > can >> >>>>> > > > > not go into branch-1, as it involves invasive changes in >> client >> >>>>> > > including >> >>>>> > > > > new RPC. As I understand the branching schema now, those >> >>>>> changes can >> >>>>> > go >> >>>>> > > > to >> >>>>> > > > > master branch, we just don't merge them to branch-1, and >> >>>>> depending on >> >>>>> > > > their >> >>>>> > > > > completeness we can pull them to 1.1 release or so. >> >>>>> > > > > >> >>>>> > > > >> >>>>> > > > You have it right Mikhail. >> >>>>> > > > >> >>>>> > > > St.Ack >> >>>>> > > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> > > -- >> >>>>> > > Thanks, >> >>>>> > > Michael Antonov >> >>>>> > > >> >>>>> > >> >>>>> >> >>>> >> >>>> >> >>> >> >> >> > >> > >
