Looks like the regular patch command skips any binary included in patches.
On Sat, Jul 19, 2014 at 1:37 AM, Aditya <adityakish...@gmail.com> wrote: > 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 >>> >>>>> > > >>> >>>>> > >>> >>>>> >>> >>>> >>> >>>> >>> >>> >>> >> >>> > >>> >> >> >
