From dev-return-45268-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Fri Mar 15 09:04:51 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 36A9A180627 for ; Fri, 15 Mar 2019 10:04:50 +0100 (CET) Received: (qmail 54689 invoked by uid 500); 15 Mar 2019 09:04:49 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 54673 invoked by uid 99); 15 Mar 2019 09:04:48 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Mar 2019 09:04:48 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id F095AC2D10 for ; Fri, 15 Mar 2019 09:04:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.125 X-Spam-Level: *** X-Spam-Status: No, score=3.125 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_REPLY=1, FROM_EXCESS_BASE64=0.105, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.313, URI_TRY_3LD=0.658] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id rriBWjR16zyT for ; Fri, 15 Mar 2019 09:04:44 +0000 (UTC) Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 403675F494 for ; Fri, 15 Mar 2019 09:04:44 +0000 (UTC) Received: by mail-ot1-f67.google.com with SMTP id z25so7730180otk.2 for ; Fri, 15 Mar 2019 02:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=yXk436BmTEjc+RI6Dv9AH3chj2+sBe2hOUqClPfOFMU=; b=hX0m/D80VWD7ExLKb/JHtJuGVnOGP8iquE/WBz+NczwoPWWozp6CelhAfD7OJ4aadg ZSNUFjjYKStg54f+irEYgW79ChLz562qdI02LSAPILIyJVN1TM/D5kQrkmLgtJFibcKk 8ZBbStOW8ks8cet07BgFYYqsDif5/WWTatNBDcRMH2b6+Fki7k5X+UiyDrwtAa5egsCJ R6fw3Ky7NKmeo2Md6jGtfjW1Wl6XnA+z2d7vnNmi9xIvRhOhUvB09VpclZFYlkdX/OmQ 9U+BnUzr+OjiCY6tds6KXj0Ub4EeQ127bZA/uv/p/4AhCaHu9nx5CpXQ0EItb0YQm54W ikQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=yXk436BmTEjc+RI6Dv9AH3chj2+sBe2hOUqClPfOFMU=; b=jF9P5BT5EmEvvWdnCGxvrIVBsC1SEMCYS9jPhtFql+UeuD/hUZANmtpS76NVRrrX09 QtcIzlGs3NbeGFm9x4zs7rKgZ28mb2rDGm+4oqzbwOmBubeWz2a4BhV8hpZfw/Y9fYXq 7a3Mb8NXwt9whvwVldIzsrngRJjjkVDnEAsOC5tDkpukXAvat1qiG25O4bL7GI2n8SkE Vkyx/CnhUFeO72o2VM9MDC8pXl1ahn/Tqvp0qceG5TDKEodlnsWSTiOTwiWV+yRwe32b S9sUgBY5jmOTG9LbwOxVG6qFC/Ber8rJJvZY2hnc0gt3y6cZ6YIgZub146XLEBuwNOez NitA== X-Gm-Message-State: APjAAAWi4lhLkOmfpGTHZ7A/ulSyHO8iff2/QcG/VmfkjyXXeXnTAa/a HBCsOi73FxmyuSl/7cFgvJ8TuWREKwFspvK7/bhx9NIC X-Google-Smtp-Source: APXvYqxMR8a1rPMh6C6d5vA03p/Lnfj5GjiP3mgaLB41TKYR3yWDsW26jYBhgw7wnNnWejpKwrq6tBZuVmg+Op0bVqQ= X-Received: by 2002:a05:6830:1258:: with SMTP id s24mr1596876otp.364.1552640683074; Fri, 15 Mar 2019 02:04:43 -0700 (PDT) MIME-Version: 1.0 References: <1549753115822-0.post@n4.nabble.com> <6D73E5EC-A96B-4194-AD06-FB765466A3BA@gmail.com> In-Reply-To: From: =?UTF-8?B?0J/QsNCy0LvRg9GF0LjQvSDQmNCy0LDQvQ==?= Date: Fri, 15 Mar 2019 12:04:31 +0300 Message-ID: Subject: Re: Code inspection To: dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree to gather some votes according to Maxim's proposal. Personally, I will not put my vote here. Both options will work for me toda= y. But I would like to say a bit about agility. As I said both options sounds fine for me today. And I believe that we can switch from one to another easily in future. Let's do our best to be flexible. =D0=BF=D1=82, 15 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 12:04, =D0=9F=D0= =B0=D0=B2=D0=BB=D1=83=D1=85=D0=B8=D0=BD =D0=98=D0=B2=D0=B0=D0=BD : > > Maxim, > > > As far as I understand your case, you want to fix all code styles > issues right before getting the final TC results. Right? ... > > Actually, I mostly worry about accidental failures. For simple tasks > my workflow looks like: > 1. Create a branch. > 2. Write some code lines and tests. > 3. Run the most closely related tests from IDEA. > 4. Push changes to the branch. > 5. Launch TC. > 6. Take a cup of coffee ;-) > 7. Check TC results after a couple of hours. > > And in such workflow I can accidentally leave styling error (IDEA does > not fail compilation). And I will receive not very valuable report > from TC. And will have to wait for another couple of hours. > > Yes, usually I do not execute "mvn clean install" locally before > triggering TC. And I think that generally we should not do it because > TC does it. > > If not everybody uses a bot visas it sounds bad for me. For patches > touching the code it should be mandatory. Also, as you might know > there are different kind of visas and for some trivial patches we can > request Checkstyle visa. Committers should check formalities. > > =D0=BF=D1=82, 15 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 10:29, Nikolay I= zhikov : > > > > +1 to enable code style checks in compile time. > > > > We can add option to disable maven codestyle profile with some environm= ent variable. > > > > Anyone who want violate common project rules in their local branch can = set this variable and write some nasty code before push :) > > > > =D0=BF=D1=82, 15 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2019 =D0=B3., 9:40 Maxi= m Muzafarov : > >> > >> Ivan, > >> > >> > 1. I can write code and execute tests successfully even if there are > >> some style problems. I can imagine that a style error can arise > >> occasionally. And instead of getting test results after several hours > >> I will get a build failure without any tests run. I will simply lose > >> my time. But if the tests are allowed to proceed I will get a red flag > >> from code style check, fix those issues and rerun style check. > >> > >> As far as I understand your case, you want to fix all code styles > >> issues right before getting the final TC results. Right? It's doable > >> you can disable checkstyle in your local branch and revet it back when > >> you've done with all your changes to get the final visa. But the > >> common case here is building the project locally and checking all > >> requirements for PR right before pushing it to the GitHub repo. I > >> always do so. The "Checklist before push" [1] have such > >> recommendations. Build the project before push will eliminate your use > >> case. > >> > >> --- > >> > >> Igniters, > >> > >> To summarize the options we have with code checking behaviour: > >> > >> 1) (code style will be broken more often) Run checkstyle in the > >> separate TC suite and include it to the Bot visa. > >> - not all of us run TC for their branches especially for simple fixes > >> (it's the most common case when a new check style errors occur) > >> - not all of us use TC.Bot visa to verify their branches > >> - if this checkstyle suite starts to fail it will be ignored for some > >> time (not blocks the development process) > >> - a lot of suites for code checking (license, checkstyle, something > >> else in future) > >> > >> + a bit comfortable way of TC tests execution for local\prototyped PRs > >> (it's a matter of taste) > >> + build the project and execute test suites a bit earlier (checkstyle > >> on the separate suite does not affect other suites) > >> > >> 2) (code style will be broken less often) Run checkstyle on project bu= ild stage. > >> - increases a bit the build time procedure > >> - require additional operations to switch it off for prototyping branc= hes > >> > >> + do not require TC.Bot visa if someone of the community doesn't use i= t > >> + code style errors will be fixed immediately if the master branch > >> starts to fail > >> + the single place for code checks on maven code validation stage > >> (license check suite can be removed) > >> > >> > >> Please, add another advantages\disadvantages that I've missed. > >> Let's vote and pick the most suitable option for the Apache Ignite nee= ds. > >> > >> --- > >> > >> Personally, I'd like to choose the 2) option. > >> > >> The JIRA [2] and PR [3] with the checkstyle enabled plugin is ready > >> for the review. > >> > >> [1] https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribu= te#HowtoContribute-Checklistbeforepush > >> [2] https://issues.apache.org/jira/browse/IGNITE-11277 > >> [3] https://github.com/apache/ignite/pull/6119 > >> > >> On Thu, 7 Mar 2019 at 11:19, =D0=9F=D0=B0=D0=B2=D0=BB=D1=83=D1=85=D0= =B8=D0=BD =D0=98=D0=B2=D0=B0=D0=BD wrote: > >> > > >> > Maxim, > >> > > >> > From use cases described by you I use only 1 and 2. And actually I > >> > think that we can concentrate on 1 and forget about others for now. > >> > But please address my worries from previous letter: > >> > =3D=3D=3D=3DQuoted text=3D=3D=3D=3D > >> > 1. I can write code and execute tests successfully even if there are > >> > some style problems. I can imagine that a style error can arise > >> > occasionally. And instead of getting test results after several hour= s > >> > I will get a build failure without any tests run. I will simply lose > >> > my time. But if the tests are allowed to proceed I will get a red fl= ag > >> > from code style check, fix those issues and rerun style check. > >> > 2. Style check takes some time. With simple checks it is almost > >> > negligible. But it can grow if more checks are involved. > >> > =3D=3D=3D=3DEnd of quoted text=3D=3D=3D=3D > >> > > >> > Some clarifications. 1 is about running from IDEA first. 2 is relate= d > >> > to opinions that we should involve much more checks, e.g. using > >> > abbreviations. > >> > > >> > =D1=87=D1=82, 7 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 10:36, Maxim= Muzafarov : > >> > > > >> > > Ivan, > >> > > > >> > > Let's take a look at all the options we have (ordered by the frequ= ency of use): > >> > > > >> > > 1. Check ready for merge branches (main case) > >> > > 2. Run tests on TC without checkstyle (prototyping branches) > >> > > 3. Local project build > >> > > 4. Quick build without any additional actions on TC > >> > > > >> > > In the other projects (kafka, netty etc.) which I've checked the c= heckstyle plugin is used in the section, so the user has no chance = in common cases to disable it via command line (correct me if I'm wrong). I= n the PR [1] I've moved checkstyle configuration to the separate profile. I= 've set activation checkstyle profile if -DskipTests specified, so it will = run with the basic build configuration. It can also be disabled locally if = we really need it. > >> > > > >> > > Back to our use cases: > >> > > > >> > > 1. For checking the ready to merge branches we will fail the ~Buil= d Apache Ignite~ suite, so no configured checkstyle rules will be violated.= If we will use the TC.Bot approach someone will merge the branch without r= unning TC.Bot on it, but no one will merge the branch with compile errors. > >> > > > >> > > 2. For the prototyping branches, you can turn off checkstyle in yo= ur local PR by removing activation configuration. It's ok as these type of = branches will never be merged to the master. > >> > > > >> > > 3. From my point, local builds should be always run with the check= style enabled profile. The common build action as `mvn clean install -Dskip= Tests` will activate the profile. > >> > > > >> > > 4. The checkstyle profile can be disabled explicitly on TC by spec= ifying -P !checkstyle option. A don't see any use cases of it, but it's com= pletely doable. > >> > > > >> > > Please, correct me if I've missed something. > >> > > > >> > > I propose to merge PR [1] as it is, with the configured set of rul= es. > >> > > > >> > > [1] https://github.com/apache/ignite/pull/6119 > >> > > > >> > > On Tue, 5 Mar 2019 at 19:02 =D0=9F=D0=B0=D0=B2=D0=BB=D1=83=D1=85= =D0=B8=D0=BD =D0=98=D0=B2=D0=B0=D0=BD wrote: > >> > >> > >> > >> Maxim, > >> > >> > >> > >> I like an idea of being IDE agnostic. I am ok with currently enab= led > >> > >> checks, they are a must-have in my opinion (even for prototypes). > >> > >> > >> > >> But I am still do not like an idea of preventing tests execution = if > >> > >> style check finds a problem. I checked out PR, installed a plugin= and > >> > >> tried it out. Here are my concerns: > >> > >> 1. I can write code and execute tests successfully even if there = are > >> > >> some style problems. I can imagine that a style error can arise > >> > >> occasionally. And instead of getting test results after several h= ours > >> > >> I will get a build failure without any tests run. I will simply l= ose > >> > >> my time. But if the tests are allowed to proceed I will get a red= flag > >> > >> from code style check, fix those issues and rerun style check. > >> > >> 2. Style check takes some time. With simple checks it is almost > >> > >> negligible. But it can grow if more checks are involved. > >> > >> > >> > >> On the bright side I found nice integration of Checkstyle plugin = with > >> > >> IDEA commit dialog. There is a checkbox "Scan with Checkstyle" wh= ich I > >> > >> think is quite useful. > >> > >> > >> > >> =D0=BF=D0=BD, 4 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 15:00, Ma= xim Muzafarov : > >> > >> > > >> > >> > Ivan, > >> > >> > > >> > >> > I like that Jetbrains inspections are integrated with IDE and T= C out > >> > >> > of the box, but currently, they are working not well enough on = TC. > >> > >> > Actually, they are not checking our source code at all. > >> > >> > > >> > >> > Let's try a bit another approach and try to be IDE-agnostic wit= h code > >> > >> > style checking. I've checked popular java projects: hadoop, kaf= ka, > >> > >> > spark, hive, netty. All of them are using maven-checkstyle-plug= in in > >> > >> > their section by default, so why don't we? It sounds > >> > >> > reasonable for me at least to try so. > >> > >> > > >> > >> > Can you take a look at my changes below? > >> > >> > > >> > >> > > >> > >> > Igniters, > >> > >> > > >> > >> > PR [2] has been prepared. All the details I've mentioned in my = comment > >> > >> > in JIRA [4]. > >> > >> > Can anyone take a look at my changes? > >> > >> > > >> > >> > JIRA: [1] > >> > >> > PR: [2] > >> > >> > Upsource: [3] > >> > >> > > >> > >> > Questions to discuss: > >> > >> > 1) There is no analogue for inspections RedundantSuppression an= d > >> > >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose t= o merge > >> > >> > without them. > >> > >> > 2) Checkstyle plugin has it's own maven profile and enabled by > >> > >> > default. It can be turned off for prototype branches. > >> > >> > 3) I've removed the inspections configuration for the TC suite = and > >> > >> > propose to disable it as not working. > >> > >> > > >> > >> > > >> > >> > [1] https://issues.apache.org/jira/browse/IGNITE-11277 > >> > >> > [2] https://github.com/apache/ignite/pull/6119 > >> > >> > [3] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-101= 8 > >> > >> > [4] https://issues.apache.org/jira/browse/IGNITE-11277?focusedC= ommentId=3D16771200&page=3Dcom.atlassian.jira.plugin.system.issuetabpanels%= 3Acomment-tabpanel#comment-16771200 > >> > >> > [5] http://checkstyle.sourceforge.net/checks.html > >> > >> > > >> > >> > On Thu, 14 Feb 2019 at 16:21, =D0=9F=D0=B0=D0=B2=D0=BB=D1=83=D1= =85=D0=B8=D0=BD =D0=98=D0=B2=D0=B0=D0=BD wrote: > >> > >> > > > >> > >> > > Nikolay, > >> > >> > > > >> > >> > > > All community members are forced to follow code style. It's= harder to achieve it with dedicated suite. > >> > >> > > Why it is easier to follow code style with use of maven check= style > >> > >> > > plugin? Is it integrated into IDEA out of box? As I got it ad= ditional > >> > >> > > IDEA plugin is needed as well. Who will enforce everybody to = install > >> > >> > > it? > >> > >> > > > >> > >> > > Also, as I see a common good practice today is using TC Bot v= isa. Visa > >> > >> > > includes result from running inspections job. > >> > >> > > > >> > >> > > =D1=87=D1=82, 14 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0= =B2 16:08, Nikolay Izhikov : > >> > >> > > > > >> > >> > > > Ivan, > >> > >> > > > > >> > >> > > > > Could you please outline the benefits you see of failing = compilation and > >> > >> > > > skipping tests execution if inspections detect a problem? > >> > >> > > > > >> > >> > > > All community members are forced to follow code style. > >> > >> > > > It's harder to achieve it with dedicated suite. > >> > >> > > > > >> > >> > > > > >> > >> > > > =D1=87=D1=82, 14 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0= =B2 15:21, =D0=9F=D0=B0=D0=B2=D0=BB=D1=83=D1=85=D0=B8=D0=BD =D0=98=D0=B2=D0= =B0=D0=BD : > >> > >> > > > > >> > >> > > > > Nikolay, > >> > >> > > > > > >> > >> > > > > > Should the community spend TC resources for prototype? > >> > >> > > > > Why not? I think it is not bad idea to run all tests agai= nst some > >> > >> > > > > changes into core classes. If I have a clever idea which = is easy to > >> > >> > > > > test drive I can do couple of prototype-test iterations. = If tests > >> > >> > > > > shows me that everything is bad then the idea was not so = clever and > >> > >> > > > > easy. But if I was lucky then I should discuss the idea w= ith other > >> > >> > > > > Igniters. I think it is the cheapest way to check the ide= a because the > >> > >> > > > > check is fully automated. Requiring a human feedback is m= uch more > >> > >> > > > > expensive in my opinion. > >> > >> > > > > > But, If our code style is not convinient for every day = coding for many > >> > >> > > > > contributors, should you initiate discussion to change it= ? > >> > >> > > > > Generally I am fine with our codestyle requirements. > >> > >> > > > > > >> > >> > > > > Also, I would like to keep a focus on the subject. Could = you please > >> > >> > > > > outline the benefits you see of failing compilation and s= kipping tests > >> > >> > > > > execution if inspections detect a problem? > >> > >> > > > > > >> > >> > > > > =D1=87=D1=82, 14 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. = =D0=B2 14:14, Nikolay Izhikov : > >> > >> > > > > > > >> > >> > > > > > Hello, Ivan. > >> > >> > > > > > > >> > >> > > > > > > Requirements for a prototype code are not the same as= for a patch ready > >> > >> > > > > > to merge > >> > >> > > > > > > >> > >> > > > > > True. > >> > >> > > > > > > >> > >> > > > > > > I do not see much need in writing good javadocs for p= rototype. > >> > >> > > > > > > >> > >> > > > > > We, as a community, can't force you to do it. > >> > >> > > > > > > >> > >> > > > > > > Why should I stub it to be able run any build on TC? > >> > >> > > > > > > >> > >> > > > > > Should the community spend TC resources for prototype? > >> > >> > > > > > You always can check tests for your prototype locally. > >> > >> > > > > > > >> > >> > > > > > And when it's ready, at least from code style point of = view run it on TC. > >> > >> > > > > > > >> > >> > > > > > I, personally, always try to follow project code style,= even for > >> > >> > > > > prototypes. > >> > >> > > > > > But, If our code style is not convinient for every day = coding for many > >> > >> > > > > > contributors, should you initiate discussion to change = it? > >> > >> > > > > > > >> > >> > > > > > > >> > >> > > > > > =D1=81=D1=80, 13 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3.= =D0=B2 16:45, =D0=9F=D0=B0=D0=B2=D0=BB=D1=83=D1=85=D0=B8=D0=BD =D0=98=D0= =B2=D0=B0=D0=BD : > >> > >> > > > > > > >> > >> > > > > > > Maxim, > >> > >> > > > > > > > >> > >> > > > > > > Oh, my poor tabs.. Joke. > >> > >> > > > > > > > >> > >> > > > > > > I am totally ok with currently enabled checks. But I = am mostly > >> > >> > > > > > > concerned about a general approach. I would like to o= utline one thing. > >> > >> > > > > > > Requirements for a prototype code are not the same as= for a patch > >> > >> > > > > > > ready to merge (see a little bit more in the end of t= hat message). > >> > >> > > > > > > > >> > >> > > > > > > We have a document defining code style which every co= ntributor should > >> > >> > > > > > > follow [1]. And many points can be checked automatica= lly. Personally, > >> > >> > > > > > > I do not see much need in writing good javadocs for p= rototype. Why > >> > >> > > > > > > should I stub it to be able run any build on TC? > >> > >> > > > > > > > >> > >> > > > > > > Also, we a have a review process which should be appl= ied to every > >> > >> > > > > > > patch. Partially it is described in [2]. And due to t= his process every > >> > >> > > > > > > patch should not introduce new failures on TC. So, th= e patch should > >> > >> > > > > > > not be merged if inspections failed. > >> > >> > > > > > > > >> > >> > > > > > > P.S. Something more about prototypes and production c= ode. There is a > >> > >> > > > > > > common bad practice in software engineering. It is tu= rning prototypes > >> > >> > > > > > > into production code. Often it is much faster to crea= te a prototype by > >> > >> > > > > > > price of violating some rules of writing "clean code"= . And often > >> > >> > > > > > > prototype after successful piloting is turned into pr= oduction code. > >> > >> > > > > > > And it is very easy in practice to keep some pieces o= f initially > >> > >> > > > > > > "dirty" prototype code. I believe human factor plays = a great role > >> > >> > > > > > > here. How should it be done right then? In my opinion= good production > >> > >> > > > > > > code should be designed as "good production code" fro= m the beginning. > >> > >> > > > > > > So, only ideas are taken from the prototype and a cod= e is fully > >> > >> > > > > > > rewritten. > >> > >> > > > > > > > >> > >> > > > > > > [1] > >> > >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding= +Guidelines > >> > >> > > > > > > [2] > >> > >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Review= +Checklist > >> > >> > > > > > > > >> > >> > > > > > > =D1=81=D1=80, 13 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0= =B3. =D0=B2 15:05, Maxim Muzafarov : > >> > >> > > > > > > > > >> > >> > > > > > > > Ivan, > >> > >> > > > > > > > > >> > >> > > > > > > > As the first implementation of this addition, I'd p= refer to make it > >> > >> > > > > > > > working like _Licenses Headers_ suite check. It wil= l fail when some > >> > >> > > > > of > >> > >> > > > > > > > the code style checks violated. Moreover, these lic= enses header > >> > >> > > > > checks > >> > >> > > > > > > > can be included in the checkstyle plugin configurat= ion. > >> > >> > > > > > > > > >> > >> > > > > > > > In general, I'd prefer to have a compilation fail e= rror with code > >> > >> > > > > > > > style checks and after we will get a stable checkst= yle suite I > >> > >> > > > > propose > >> > >> > > > > > > > to change it in a "compilation error" way. If we ar= e talking about > >> > >> > > > > the > >> > >> > > > > > > > coding style convenient for most of the community m= embers I see no > >> > >> > > > > > > > difference with coding sketches or production-ready= branches equally. > >> > >> > > > > > > > Indeed, no one will be against unused imports [or s= paces instead of > >> > >> > > > > > > > tabs :-) ] in their PRs or prototypes, right? (for = instance, it can > >> > >> > > > > be > >> > >> > > > > > > > automatically removed by IDE at commit phase). > >> > >> > > > > > > > > >> > >> > > > > > > > Please, note currently enabled checks are: > >> > >> > > > > > > > - list.isEmpty() instead of list.size() =3D=3D 0 > >> > >> > > > > > > > - unused imports > >> > >> > > > > > > > - missing @Override > >> > >> > > > > > > > - sotred modifiers checks (e.g. pulic static final= ..) > >> > >> > > > > > > > - redundunt suppersion checks > >> > >> > > > > > > > - spaces insted of tabs. > >> > >> > > > > > > > > >> > >> > > > > > > > Are you really what to violate these checks in your= sketches? Hope > >> > >> > > > > not > >> > >> > > > > > > :-) > >> > >> > > > > > > > > >> > >> > > > > > > > On Wed, 13 Feb 2019 at 10:25, Nikolay Izhikov > >> > >> > > > > > > wrote: > >> > >> > > > > > > > > > >> > >> > > > > > > > > Actually, I dont see anything wrong with failing = *compilation* > >> > >> > > > > task. > >> > >> > > > > > > > > > >> > >> > > > > > > > > I think one should use project code style for eve= ryday coding, not > >> > >> > > > > > > only for > >> > >> > > > > > > > > ready-to-merge PRs. > >> > >> > > > > > > > > > >> > >> > > > > > > > > If we cant use code style for everyday coding, we= should change the > >> > >> > > > > > > > > codestyle. > >> > >> > > > > > > > > > >> > >> > > > > > > > > What do you think? > >> > >> > > > > > > > > > >> > >> > > > > > > > > =D1=81=D1=80, 13 =D1=84=D0=B5=D0=B2=D1=80. 2019 = =D0=B3., 10:11 Petr Ivanov mr.weider@gmail.com: > >> > >> > > > > > > > > > >> > >> > > > > > > > > > I guess that was about failing build configurat= ion with > >> > >> > > > > Checkstype, > >> > >> > > > > > > not > >> > >> > > > > > > > > > compilation build itself. > >> > >> > > > > > > > > > > >> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03, =D0=9F=D0=B0=D0=B2= =D0=BB=D1=83=D1=85=D0=B8=D0=BD =D0=98=D0=B2=D0=B0=D0=BD > >> > >> > > > > > > wrote: > >> > >> > > > > > > > > > > > >> > >> > > > > > > > > > > Folks, > >> > >> > > > > > > > > > > > >> > >> > > > > > > > > > > Are you going to fail job compiling Ignite so= urces [1] if some > >> > >> > > > > > > > > > > inspection found a problem? Can we avoid it? = It is quite common > >> > >> > > > > > > > > > > pattern to start some feature implementation = with making a > >> > >> > > > > sketch > >> > >> > > > > > > and > >> > >> > > > > > > > > > > running tests against it. I found it convenie= nt to skip some > >> > >> > > > > style > >> > >> > > > > > > > > > > requirements for such sketches (e.g. well for= med javadocs). > >> > >> > > > > > > > > > > > >> > >> > > > > > > > > > > [1] > >> > >> > > > > > > > > > > >> > >> > > > > > > > >> > >> > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=3D= IgniteTests24Java8_BuildApacheIgnite > >> > >> > > > > > > > > > > > >> > >> > > > > > > > > > > =D0=BF=D0=BD, 11 =D1=84=D0=B5=D0=B2=D1=80. 20= 19 =D0=B3. =D0=B2 11:38, Nikolay Izhikov < > >> > >> > > > > nizhikov@apache.org > >> > >> > > > > > > >: > >> > >> > > > > > > > > > >> > >> > >> > > > > > > > > > >> Petr, we should have 1 configuration for pro= ject, may be 1 > >> > >> > > > > > > configuration > >> > >> > > > > > > > > > >> per programming language. > >> > >> > > > > > > > > > >> > >> > >> > > > > > > > > > >> =D0=BF=D0=BD, 11 =D1=84=D0=B5=D0=B2=D1=80. 2= 019 =D0=B3., 11:33 Petr Ivanov mr.weider@gmail.com: > >> > >> > > > > > > > > > >> > >> > >> > > > > > > > > > >>> I was asking about how many build configura= tion is intended? > >> > >> > > > > One > >> > >> > > > > > > for > >> > >> > > > > > > > > > all > >> > >> > > > > > > > > > >>> and multiple per module? > >> > >> > > > > > > > > > >>> > >> > >> > > > > > > > > > >>> With IDEA inspections it was going to be bu= ild configuration > >> > >> > > > > per > >> > >> > > > > > > > > > module. > >> > >> > > > > > > > > > >>> > >> > >> > > > > > > > > > >>> > >> > >> > > > > > > > > > >>> > >> > >> > > > > > > > > > >>> > >> > >> > > > > > > > > > >>>> On 11 Feb 2019, at 11:24, Nikolay Izhikov = < > >> > >> > > > > nizhikov@apache.org> > >> > >> > > > > > > > > > wrote: > >> > >> > > > > > > > > > >>>> > >> > >> > > > > > > > > > >>>> Hello, Petr. > >> > >> > > > > > > > > > >>>> > >> > >> > > > > > > > > > >>>> Are you saying that we have not single bui= ld task? And each > >> > >> > > > > > > module > >> > >> > > > > > > > > > builds > >> > >> > > > > > > > > > >>>> when it required? If yes, then I propose t= o create a task > >> > >> > > > > like > >> > >> > > > > > > > > > "Licence > >> > >> > > > > > > > > > >>>> check" which will be run for every patch. > >> > >> > > > > > > > > > >>>> > >> > >> > > > > > > > > > >>>> My point is that violation of codestyle sh= ould be treated as > >> > >> > > > > > > hard as > >> > >> > > > > > > > > > >>>> compile error. > >> > >> > > > > > > > > > >>>> > >> > >> > > > > > > > > > >>>> =D0=BF=D0=BD, 11 =D1=84=D0=B5=D0=B2=D1=80.= 2019 =D0=B3., 11:16 Petr Ivanov mr.weider@gmail.com > >> > >> > > > > : > >> > >> > > > > > > > > > >>>> > >> > >> > > > > > > > > > >>>>> Is build configuration Inspections [Core]= meant to > >> > >> > > > > transform > >> > >> > > > > > > into > >> > >> > > > > > > > > > single > >> > >> > > > > > > > > > >>>>> all-modules check build configuration (wi= thout module > >> > >> > > > > > > subdivision)? > >> > >> > > > > > > > > > >>>>> > >> > >> > > > > > > > > > >>>>> > >> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhiko= v < > >> > >> > > > > > > nizhikov@apache.org> > >> > >> > > > > > > > > > wrote: > >> > >> > > > > > > > > > >>>>>> > >> > >> > > > > > > > > > >>>>>> Hello, Maxim. > >> > >> > > > > > > > > > >>>>>> > >> > >> > > > > > > > > > >>>>>> +1 from me for migrating to checkstyle. > >> > >> > > > > > > > > > >>>>>> > >> > >> > > > > > > > > > >>>>>> Oleg, there is plugin for IDEA with 2mln= downloads - > >> > >> > > > > > > > > > >>>>>> https://plugins.jetbrains.com/plugin/106= 5-checkstyle-idea > >> > >> > > > > > > > > > >>>>>> > >> > >> > > > > > > > > > >>>>>> I propose do the following: > >> > >> > > > > > > > > > >>>>>> > >> > >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle. > >> > >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules. C= urrently, only > >> > >> > > > > core > >> > >> > > > > > > module > >> > >> > > > > > > > > > are > >> > >> > > > > > > > > > >>>>>> checked. > >> > >> > > > > > > > > > >>>>>> I will review and commit this patch, or = do it by my own. > >> > >> > > > > > > > > > >>>>>> > >> > >> > > > > > > > > > >>>>>> 3. Include code style checks to "Build A= pache Ignite" > >> > >> > > > > suite. > >> > >> > > > > > > Ignite > >> > >> > > > > > > > > > has > >> > >> > > > > > > > > > >>>>> to > >> > >> > > > > > > > > > >>>>>> fail to build if patch violates codestyl= e. > >> > >> > > > > > > > > > >>>>>> > >> > >> > > > > > > > > > >>>>>> =D0=B2=D1=81, 10 =D1=84=D0=B5=D0=B2=D1= =80. 2019 =D0=B3. =D0=B2 07:54, =D0=9F=D0=B0=D0=B2=D0=BB=D1=83=D1=85=D0=B8= =D0=BD =D0=98=D0=B2=D0=B0=D0=BD < > >> > >> > > > > > > vololo100@gmail.com>: > >> > >> > > > > > > > > > >>>>>> > >> > >> > > > > > > > > > >>>>>>> Hi, > >> > >> > > > > > > > > > >>>>>>> > >> > >> > > > > > > > > > >>>>>>> I also think that some warning from IDE= A that some code > >> > >> > > > > > > style rule > >> > >> > > > > > > > > > is > >> > >> > > > > > > > > > >>>>>>> violated is a must-have. > >> > >> > > > > > > > > > >>>>>>> > >> > >> > > > > > > > > > >>>>>>> =D0=B2=D1=81, 10 =D1=84=D0=B5=D0=B2=D1= =80. 2019 =D0=B3. =D0=B2 01:58, oignatenko < > >> > >> > > > > > > oignatenko@gridgain.com > >> > >> > > > > > > > > > >: > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> Hi Maxim, > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> I believe that whatever style checks w= e establish at > >> > >> > > > > > > Teamcity, we > >> > >> > > > > > > > > > >>>>> better > >> > >> > > > > > > > > > >>>>>>>> take care of making it easy for develo= pers to find and > >> > >> > > > > fix > >> > >> > > > > > > > > > violations > >> > >> > > > > > > > > > >>>>> in > >> > >> > > > > > > > > > >>>>>>>> their typical dev environment (for Ign= ite this means, in > >> > >> > > > > > > IDEA). I > >> > >> > > > > > > > > > >>> think > >> > >> > > > > > > > > > >>>>>>> it > >> > >> > > > > > > > > > >>>>>>>> is important that developers can maint= ain required style > >> > >> > > > > > > with > >> > >> > > > > > > > > > minimal > >> > >> > > > > > > > > > >>>>>>> effort > >> > >> > > > > > > > > > >>>>>>>> on their side. > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> If above is doable then I am 200% for = migrating our > >> > >> > > > > Teamcity > >> > >> > > > > > > > > > >>>>> inspections > >> > >> > > > > > > > > > >>>>>>> to > >> > >> > > > > > > > > > >>>>>>>> checkstyle / maven. > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> This is because I am very disappointed= observing how it > >> > >> > > > > > > stays > >> > >> > > > > > > > > > broken > >> > >> > > > > > > > > > >>>>> for > >> > >> > > > > > > > > > >>>>>>> so > >> > >> > > > > > > > > > >>>>>>>> long. And worst of all, even when (if)= it is fixed, I > >> > >> > > > > feel > >> > >> > > > > > > we will > >> > >> > > > > > > > > > >>>>>>> always be > >> > >> > > > > > > > > > >>>>>>>> at risk that it breaks again and that = we will have to > >> > >> > > > > again > >> > >> > > > > > > wait > >> > >> > > > > > > > > > for > >> > >> > > > > > > > > > >>>>>>> months > >> > >> > > > > > > > > > >>>>>>>> for it to be fixed. > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> This is such a stark contrast with my = experience > >> > >> > > > > regarding > >> > >> > > > > > > > > > checkstyle > >> > >> > > > > > > > > > >>>>>>> based > >> > >> > > > > > > > > > >>>>>>>> inspections. These just work and you j= ust never fear > >> > >> > > > > that > >> > >> > > > > > > it is > >> > >> > > > > > > > > > going > >> > >> > > > > > > > > > >>>>> to > >> > >> > > > > > > > > > >>>>>>>> break for some obscure reason, this is= so much better > >> > >> > > > > than > >> > >> > > > > > > what I > >> > >> > > > > > > > > > >>>>> observe > >> > >> > > > > > > > > > >>>>>>>> now. > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> One suggestion in case if we pick chec= kstyle - I > >> > >> > > > > recommend > >> > >> > > > > > > keeping > >> > >> > > > > > > > > > >>> its > >> > >> > > > > > > > > > >>>>>>>> config file somewhere in the project u= nder version > >> > >> > > > > control. > >> > >> > > > > > > I > >> > >> > > > > > > > > > used to > >> > >> > > > > > > > > > >>>>>>>> maintain such a shared style config at= one of past jobs > >> > >> > > > > and > >> > >> > > > > > > after > >> > >> > > > > > > > > > >>> some > >> > >> > > > > > > > > > >>>>>>>> experimenting it turned out most conve= nient to have it > >> > >> > > > > this > >> > >> > > > > > > way - > >> > >> > > > > > > > > > so > >> > >> > > > > > > > > > >>>>> that > >> > >> > > > > > > > > > >>>>>>>> developers could easily assess and dis= cuss style > >> > >> > > > > settings > >> > >> > > > > > > and keep > >> > >> > > > > > > > > > >>>>> track > >> > >> > > > > > > > > > >>>>>>> of > >> > >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka folk= s from your link > >> > >> > > > > [5] > >> > >> > > > > > > appear > >> > >> > > > > > > > > > to > >> > >> > > > > > > > > > >>> be > >> > >> > > > > > > > > > >>>>>>>> doing it this way) > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> regards, Oleg > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> Mmuzaf wrote > >> > >> > > > > > > > > > >>>>>>>>> Igniters, > >> > >> > > > > > > > > > >>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> I've found that some of the community= members have > >> > >> > > > > faced > >> > >> > > > > > > with > >> > >> > > > > > > > > > >>>>>>>>> `[Inspections] Core suite [1]` is not= working well > >> > >> > > > > enough > >> > >> > > > > > > on TC. > >> > >> > > > > > > > > > The > >> > >> > > > > > > > > > >>>>>>>>> suite has a `FAILED` status for more = than 2 months due > >> > >> > > > > to > >> > >> > > > > > > some > >> > >> > > > > > > > > > >>> issues > >> > >> > > > > > > > > > >>>>>>>>> in TeamCity application [2]. Current = suite behaviour > >> > >> > > > > > > confuses not > >> > >> > > > > > > > > > >>> only > >> > >> > > > > > > > > > >>>>>>>>> new contributors but also other commu= nity members. > >> > >> > > > > > > Moreover, this > >> > >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we pr= eviously > >> > >> > > > > configured. > >> > >> > > > > > > For > >> > >> > > > > > > > > > >>>>>>>>> instance, in the master branch, I've = found 11 `Unused > >> > >> > > > > > > imports` > >> > >> > > > > > > > > > which > >> > >> > > > > > > > > > >>>>>>>>> should have been caught earlier (e.g.= for > >> > >> > > > > > > > > > >>>>>>>>> {{IgniteCachePutAllRestartTest} [3]). > >> > >> > > > > > > > > > >>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> I think we should make the next step = to enable an > >> > >> > > > > > > automatic code > >> > >> > > > > > > > > > >>> style > >> > >> > > > > > > > > > >>>>>>>>> checks. As an example, we can conside= r the Apache Kafka > >> > >> > > > > > > code > >> > >> > > > > > > > > > style > >> > >> > > > > > > > > > >>> [5] > >> > >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite proj= ect a > >> > >> > > > > > > > > > maven-checkstyle-plugin > >> > >> > > > > > > > > > >>>>>>>>> with its own maven profile and run it= simultaneously > >> > >> > > > > with > >> > >> > > > > > > other > >> > >> > > > > > > > > > TC. > >> > >> > > > > > > > > > >>> We > >> > >> > > > > > > > > > >>>>>>>>> can also enable the previously config= ured inspection > >> > >> > > > > > > rules, so no > >> > >> > > > > > > > > > >>>>>>>>> coding style violations will be misse= d. > >> > >> > > > > > > > > > >>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> I see some advantages of using a mave= n plugin: > >> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks > >> > >> > > > > > > > > > >>>>>>>>> - can be used with different CI and b= uild tools > >> > >> > > > > (Jenkins, > >> > >> > > > > > > TC) > >> > >> > > > > > > > > > >>>>>>>>> - executable from the command line > >> > >> > > > > > > > > > >>>>>>>>> - the entry single point to configure= new rules > >> > >> > > > > > > > > > >>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> I've created the ticket [4] and will = prepare PR for it. > >> > >> > > > > > > > > > >>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> WDYT? > >> > >> > > > > > > > > > >>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> [1] > >> > >> > > > > > > > > > >>>>>>>>> > >> > >> > > > > > > > > > >>>>>>> > >> > >> > > > > > > > > > >>>>> > >> > >> > > > > > > > > > >>> > >> > >> > > > > > > > > > > >> > >> > > > > > > > >> > >> > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=3D= IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=3D%3Cdefault%3= E&tab=3DbuildTypeStatusDiv > >> > >> > > > > > > > > > >>>>>>>>> [2] https://youtrack.jetbrains.com/is= sue/TW-58504 > >> > >> > > > > > > > > > >>>>>>>>> [3] > >> > >> > > > > > > > > > >>>>>>> > >> > >> > > > > > > > > > >>>>> > >> > >> > > > > > > > > > >>> > >> > >> > > > > > > > > > > >> > >> > > > > > > > >> > >> > > > > https://github.com/apache/ignite/blob/master/modules/core= /src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAl= lRestartTest.java#L29 > >> > >> > > > > > > > > > >>>>>>>>> [4] https://issues.apache.org/jira/br= owse/IGNITE-11277 > >> > >> > > > > > > > > > >>>>>>>>> [5] > >> > >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle > >> > >> > > > > > > > > > >>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Iv= anov < > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@ > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> > wrote: > >> > >> > > > > > > > > > >>>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest 2018= .2 TeamCity > >> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1] > >> > >> > > > > > > > > > >>>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>>> [1] https://youtrack.jetbrains.com/i= ssue/TW-58504 > >> > >> > > > > > > > > > >>>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivan= ov < > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@ > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> > wrote: > >> > >> > > > > > > > > > >>>>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by. > >> > >> > > > > > > > > > >>>>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy = Pavlov < > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> dpavlov@ > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>> > wrote: > >> > >> > > > > > > > > > >>>>>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>>>>> Both patches were applied. Maxim, = thank you! > >> > >> > > > > > > > > > >>>>>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>>>>> What about 1. An `Unexpected error= during build > >> > >> > > > > messages > >> > >> > > > > > > > > > >>>>>>> processing in > >> > >> > > > > > > > > > >>>>>>>>>>>> TeamCity`, what can we do as the n= ext step to fix > >> > >> > > > > it? > >> > >> > > > > > > > > > >>>>>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>>>>> Sincerely, > >> > >> > > > > > > > > > >>>>>>>>>>>> Dmitriy Pavlov > >> > >> > > > > > > > > > >>>>>>>>>>>> [cut] > >> > >> > > > > > > > > > >>>>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> > >> > >> > > > > > > > > > >>>>>>>> -- > >> > >> > > > > > > > > > >>>>>>>> Sent from: > >> > >> > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com= / > >> > >> > > > > > > > > > >>>>>>> > >> > >> > > > > > > > > > >>>>>>> > >> > >> > > > > > > > > > >>>>>>> > >> > >> > > > > > > > > > >>>>>>> -- > >> > >> > > > > > > > > > >>>>>>> Best regards, > >> > >> > > > > > > > > > >>>>>>> Ivan Pavlukhin > >> > >> > > > > > > > > > >>>>>>> > >> > >> > > > > > > > > > >>>>> > >> > >> > > > > > > > > > >>>>> > >> > >> > > > > > > > > > >>> > >> > >> > > > > > > > > > >>> > >> > >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > >> > > > > > > > > > > -- > >> > >> > > > > > > > > > > Best regards, > >> > >> > > > > > > > > > > Ivan Pavlukhin > >> > >> > > > > > > > > > > >> > >> > > > > > > > > > > >> > >> > > > > > > > >> > >> > > > > > > > >> > >> > > > > > > > >> > >> > > > > > > -- > >> > >> > > > > > > Best regards, > >> > >> > > > > > > Ivan Pavlukhin > >> > >> > > > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > -- > >> > >> > > > > Best regards, > >> > >> > > > > Ivan Pavlukhin > >> > >> > > > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > -- > >> > >> > > Best regards, > >> > >> > > Ivan Pavlukhin > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> Best regards, > >> > >> Ivan Pavlukhin > >> > > > >> > > -- > >> > > -- > >> > > Maxim Muzafarov > >> > > >> > > >> > > >> > -- > >> > Best regards, > >> > Ivan Pavlukhin > >> > > > -- > Best regards, > Ivan Pavlukhin --=20 Best regards, Ivan Pavlukhin