From dev-return-45813-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Tue Apr 23 09:26:18 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 [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 55738180621 for ; Tue, 23 Apr 2019 11:26:17 +0200 (CEST) Received: (qmail 40634 invoked by uid 500); 23 Apr 2019 09:26:16 -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 40619 invoked by uid 99); 23 Apr 2019 09:26:15 -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; Tue, 23 Apr 2019 09:26:15 +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 47657C23DC for ; Tue, 23 Apr 2019 09:26:15 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.285 X-Spam-Level: ** X-Spam-Status: No, score=2.285 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.163, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.313, URI_TRY_3LD=0.335] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id qPBeWiF29FDd for ; Tue, 23 Apr 2019 09:26:11 +0000 (UTC) Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 3A76E5FB4E for ; Tue, 23 Apr 2019 09:26:11 +0000 (UTC) Received: by mail-lf1-f66.google.com with SMTP id h18so11141381lfj.11 for ; Tue, 23 Apr 2019 02:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rzgMZYOu0QmGjjyrE7OuRk0LrkoLVQxOkY8qBhP/2Zc=; b=LgTjaZmXhF+AFJsJxGcnD+NYB5qRzGatxjXhWhd1iWllobhbWaXHawOJry1effp/uA Sb7z5zvM2hZY8BjW6QXIh26Xn/2HXzn2HwSL7bzmVlxHDO5M71kBdhOEtaEHOHZGIzFz m5vGp5Ei8gSe5TpGEtKkwl3caVlDoyLrPPa9SP94YsyGcB84Casv2U16MVWSy9x6Xpmk LQUFLMNdRsnyuGCjczooT4+OS/yT69yMefnm8wKfhXo3ngcKL8fO22hbuhu5VLx/DmlK TUPN2f3RHWphrgg301CG/VVTEP1WNqhzJTvPLGAuBJHE0CUvhsOkWe+wpbwogDXAPZuq lIbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rzgMZYOu0QmGjjyrE7OuRk0LrkoLVQxOkY8qBhP/2Zc=; b=o+qsbJo5hZXTf6T7JWaKxjtYCqgfQvu2+05OXR5JGUGUerZf0VqV+urvO9O/cUDyi8 dLX/vl4lf/lDN5ISKI2jZlMRQs2fzHpIBegsAvkTrwgI+v5psjLPhrbekmS2oYZBCzrl YGUbCJOn67AYM21L8fjBVzFGWRVBg/TBp2hoLefEDL0WTKkOducqA0DrcYNzD7H08z16 uwdasHmuAOOJUMbpMwKFqeTHqhmaW2tQVWi4qwcLuPD+poacXjFv4xgKTvTH7NC1m+/Z 1ZFNLyRHOTZm5WR3I5C0VMy5Wv9JJYBhxDOTO9Ow1P0S/bFnpcC1VN9iP7dS3Eq/qpTf ZmSw== X-Gm-Message-State: APjAAAWHRbkT/foo5txmY3PsNN9GWiHHlfaRBJaZUEg/8O+be4RaflsC uMTt90yGTelznwS3iLcELx8= X-Google-Smtp-Source: APXvYqw88bvHbk9o4tS6WFpKnB+Gamjo6woggZJQXC9BGGiJeBEVexLHL0v+aIVH+SDCnn9y/b6Jsg== X-Received: by 2002:a19:6911:: with SMTP id e17mr12838655lfc.5.1556011570331; Tue, 23 Apr 2019 02:26:10 -0700 (PDT) Received: from vveider-macbookpro2018.gridgain.local ([195.239.208.174]) by smtp.gmail.com with ESMTPSA id z7sm3599234lfg.40.2019.04.23.02.26.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Apr 2019 02:26:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Code inspection From: Petr Ivanov In-Reply-To: Date: Tue, 23 Apr 2019 12:26:08 +0300 Cc: dev@ignite.apache.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1549753115822-0.post@n4.nabble.com> <6D73E5EC-A96B-4194-AD06-FB765466A3BA@gmail.com> To: Vyacheslav Daradur X-Mailer: Apple Mail (2.3445.102.3) Vyacheslav, can you check this build please [1] if everything was ran as = expected? Also I still strictly against adding checkstyle to project build as = minor issues in checkstyle should not be blocker for test run. [1] = https://ci.ignite.apache.org/viewLog.html?buildId=3D3678000&buildTypeId=3D= IgniteTests24Java8_CheckCodeStyle&tab=3Dartifacts&branch_IgniteTests24Java= 8=3D%3Cdefault%3E# > On 23 Apr 2019, at 11:59, Petr Ivanov wrote: >=20 > I'll check it. >=20 >=20 > Also, please pass TC build for review next time and do not add to Run = All without it. >=20 > Thanks! >=20 >=20 >> On 23 Apr 2019, at 11:53, Vyacheslav Daradur = wrote: >>=20 >> This is quite strange error, in case of "install" phase it'd be = better >> just add "checkstyle" profile to "Build" [1] configuration. >>=20 >> [1] = https://ci.ignite.apache.org/viewType.html?buildTypeId=3DIgniteTests24Java= 8_BuildApacheIgnite >>=20 >> On Tue, Apr 23, 2019 at 11:43 AM Petr Ivanov = wrote: >>>=20 >>> The suite is malformed. >>> If no ~/.m2/repository/org/apache/ignite artifact are installed in = system, the build will fail [1] >>>=20 >>> It seems that we should use install instead of validate. >>>=20 >>>=20 >>> [1] = https://ci.ignite.apache.org/viewLog.html?tab=3DbuildLog&logTab=3Dtree&fil= ter=3Ddebug&expand=3Dall&buildId=3D3677858&_focus=3D288 >>>=20 >>>=20 >>> On 23 Apr 2019, at 00:25, Vyacheslav Daradur = wrote: >>>=20 >>> Maxim, I merged your changes to master. >>>=20 >>> Also, I've created a new build plan "Check Code Style" on TC [1] and >>> included in RunAll build. >>> The report of check-style attaches in artifacts once build is = finished. >>>=20 >>> Please check that it works as expected once again and announce new >>> requirements in a separate thread to avoid confusion of community. >>>=20 >>> cc Petr, Pavel (JFYI) >>>=20 >>> [1] = https://ci.ignite.apache.org/viewType.html?buildTypeId=3DIgniteTests24Java= 8_CheckCodeStyle&tab=3DbuildTypeBranches >>>=20 >>> On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur = wrote: >>>=20 >>>=20 >>> Maxim, >>>=20 >>> I left some comments in Jira, let's resolve them and I'll assist you >>> with merge and TC configuring. >>>=20 >>> On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov = wrote: >>>=20 >>>=20 >>> Vyacheslav, >>>=20 >>> Thank you for your interest in making Ignite coding style better. >>>=20 >>> The short answer is - there are no different checkstyle >>> configurations. One for the JetBrains Inspections, and one the >>> Checkstyle plugin. This is a completely different approach for >>> checking the Ignites source code. >>>=20 >>> Currently, we have two different configurations for the JetBrains = IDEA >>> Inspection check: >>> - ignite\.idea\inspectionProfiles\Project_Default.xml - this is >>> default on the IDE level and used silently by every developer whos >>> checkout Ignite project (it remains) >>> - ignite\idea\ignite_inspections_teamcity.xml - this is the >>> configuration of the inspection for the TC suite (it will be = deleted) >>> It's unobvious to maintain both of them. Previously we've planned to >>> fix all the inspection rules one by one and add them one by one to = the >>> TC inspection configuration file (something like storing the >>> intermediate result), but it didn't happen cause the inspection TC >>> suite got broken after migration to 2018 version. >>>=20 >>> Now it seems to me, that it is better to use the best open source >>> practices like checkstyle plugin (380K usages on github = repositories) >>> rather than proprietary software. So, we will: >>> - keep IDE level inspection configuration (the Project_Default.xml = config); >>> - add a new checkstyle plugin configuration file (checkstyle.xml >>> config) which will be used simultaneously for checking code style on >>> build procedure and for the IDE-checkstyle plugin; >>>=20 >>> On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur = wrote: >>>=20 >>>=20 >>> Maxim, >>>=20 >>> I looked through the PR and it looks good to me in general. >>>=20 >>> The only question how it's planned to maintain check styles in 2 >>> different configurations, for IDEA and check style plugin? >>>=20 >>> On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov = wrote: >>>=20 >>>=20 >>> Igniters, >>>=20 >>> The issue [1] with enabled maven-checkstyle-plugin is ready for the = review. >>> All changes are prepared according to e-mail [2] the second option >>> point (include the plugin in the maven build procedure by default). >>>=20 >>> JIRA: IGNITE-11277 [1] >>> PR: [3] >>> Upsource: [4] >>>=20 >>> How can take a look? >>>=20 >>> [1] https://issues.apache.org/jira/browse/IGNITE-11277 >>> [2] = http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27= 709p41297.html >>> [3] https://github.com/apache/ignite/pull/6119 >>> [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018 >>>=20 >>> On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov = wrote: >>>=20 >>>=20 >>> Hi Igniters, >>>=20 >>> I see that a new TeamCity is released: Version: 2018.2.3. >>>=20 >>> Probably it could solve recently introduced problem related to: >>> Unexpected error during build messages processing in TeamCity; >>>=20 >>> Peter I., could you please check? >>>=20 >>> Sincerely, >>> Dmitriy Pavlov >>>=20 >>> =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 = : >>>=20 >>> I agree to gather some votes according to Maxim's proposal. >>>=20 >>> Personally, I will not put my vote here. Both options will work for = me >>> today. >>>=20 >>> 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. >>>=20 >>> =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 = : >>>=20 >>>=20 >>> Maxim, >>>=20 >>> As far as I understand your case, you want to fix all code styles >>>=20 >>> issues right before getting the final TC results. Right? ... >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> =D0=BF=D1=82, 15 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 10:29, = Nikolay Izhikov : >>>=20 >>>=20 >>> +1 to enable code style checks in compile time. >>>=20 >>> We can add option to disable maven codestyle profile with some >>>=20 >>> environment variable. >>>=20 >>>=20 >>> Anyone who want violate common project rules in their local branch = can >>>=20 >>> set this variable and write some nasty code before push :) >>>=20 >>>=20 >>> =D0=BF=D1=82, 15 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2019 =D0=B3., 9:40 = Maxim Muzafarov : >>>=20 >>>=20 >>> Ivan, >>>=20 >>> 1. I can write code and execute tests successfully even if there are >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> --- >>>=20 >>> Igniters, >>>=20 >>> To summarize the options we have with code checking behaviour: >>>=20 >>> 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) >>>=20 >>> + 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) >>>=20 >>> 2) (code style will be broken less often) Run checkstyle on project >>>=20 >>> build stage. >>>=20 >>> - increases a bit the build time procedure >>> - require additional operations to switch it off for prototyping >>>=20 >>> branches >>>=20 >>>=20 >>> + do not require TC.Bot visa if someone of the community doesn't use >>>=20 >>> it >>>=20 >>> + 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) >>>=20 >>>=20 >>> Please, add another advantages\disadvantages that I've missed. >>> Let's vote and pick the most suitable option for the Apache Ignite >>>=20 >>> needs. >>>=20 >>>=20 >>> --- >>>=20 >>> Personally, I'd like to choose the 2) option. >>>=20 >>> The JIRA [2] and PR [3] with the checkstyle enabled plugin is ready >>> for the review. >>>=20 >>> [1] >>>=20 >>> = https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#Howto= Contribute-Checklistbeforepush >>>=20 >>> [2] https://issues.apache.org/jira/browse/IGNITE-11277 >>> [3] https://github.com/apache/ignite/pull/6119 >>>=20 >>> 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 >>>=20 >>> wrote: >>>=20 >>>=20 >>> Maxim, >>>=20 >>> =46rom 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 >>>=20 >>> hours >>>=20 >>> 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 >>>=20 >>> flag >>>=20 >>> 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 >>>=20 >>> Some clarifications. 1 is about running from IDEA first. 2 is >>>=20 >>> related >>>=20 >>> to opinions that we should involve much more checks, e.g. using >>> abbreviations. >>>=20 >>> =D1=87=D1=82, 7 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 10:36, Maxim = Muzafarov : >>>=20 >>>=20 >>> Ivan, >>>=20 >>> Let's take a look at all the options we have (ordered by the >>>=20 >>> frequency of use): >>>=20 >>>=20 >>> 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 >>>=20 >>> In the other projects (kafka, netty etc.) which I've checked the >>>=20 >>> checkstyle 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). >>> In 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. >>>=20 >>>=20 >>> Back to our use cases: >>>=20 >>> 1. For checking the ready to merge branches we will fail the >>>=20 >>> ~Build 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 running TC.Bot on it, but no one will merge the branch with = compile >>> errors. >>>=20 >>>=20 >>> 2. For the prototyping branches, you can turn off checkstyle in >>>=20 >>> your local PR by removing activation configuration. It's ok as these = type >>> of branches will never be merged to the master. >>>=20 >>>=20 >>> 3. =46rom my point, local builds should be always run with the >>>=20 >>> checkstyle enabled profile. The common build action as `mvn clean = install >>> -DskipTests` will activate the profile. >>>=20 >>>=20 >>> 4. The checkstyle profile can be disabled explicitly on TC by >>>=20 >>> specifying -P !checkstyle option. A don't see any use cases of it, = but it's >>> completely doable. >>>=20 >>>=20 >>> Please, correct me if I've missed something. >>>=20 >>> I propose to merge PR [1] as it is, with the configured set of >>>=20 >>> rules. >>>=20 >>>=20 >>> [1] https://github.com/apache/ignite/pull/6119 >>>=20 >>> 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 >>>=20 >>> wrote: >>>=20 >>>=20 >>> Maxim, >>>=20 >>> I like an idea of being IDE agnostic. I am ok with currently >>>=20 >>> enabled >>>=20 >>> checks, they are a must-have in my opinion (even for prototypes). >>>=20 >>> But I am still do not like an idea of preventing tests execution >>>=20 >>> if >>>=20 >>> style check finds a problem. I checked out PR, installed a >>>=20 >>> plugin and >>>=20 >>> tried it out. Here are my concerns: >>> 1. I can write code and execute tests successfully even if there >>>=20 >>> are >>>=20 >>> some style problems. I can imagine that a style error can arise >>> occasionally. And instead of getting test results after several >>>=20 >>> hours >>>=20 >>> I will get a build failure without any tests run. I will simply >>>=20 >>> lose >>>=20 >>> my time. But if the tests are allowed to proceed I will get a >>>=20 >>> red flag >>>=20 >>> 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. >>>=20 >>> On the bright side I found nice integration of Checkstyle plugin >>>=20 >>> with >>>=20 >>> IDEA commit dialog. There is a checkbox "Scan with Checkstyle" >>>=20 >>> which I >>>=20 >>> think is quite useful. >>>=20 >>> =D0=BF=D0=BD, 4 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 15:00, Maxim = Muzafarov >>=20 >>> : >>>=20 >>>=20 >>> Ivan, >>>=20 >>> I like that Jetbrains inspections are integrated with IDE and >>>=20 >>> TC out >>>=20 >>> of the box, but currently, they are working not well enough on >>>=20 >>> TC. >>>=20 >>> Actually, they are not checking our source code at all. >>>=20 >>> Let's try a bit another approach and try to be IDE-agnostic >>>=20 >>> with code >>>=20 >>> style checking. I've checked popular java projects: hadoop, >>>=20 >>> kafka, >>>=20 >>> spark, hive, netty. All of them are using >>>=20 >>> maven-checkstyle-plugin in >>>=20 >>> their section by default, so why don't we? It sounds >>> reasonable for me at least to try so. >>>=20 >>> Can you take a look at my changes below? >>>=20 >>>=20 >>> Igniters, >>>=20 >>> PR [2] has been prepared. All the details I've mentioned in my >>>=20 >>> comment >>>=20 >>> in JIRA [4]. >>> Can anyone take a look at my changes? >>>=20 >>> JIRA: [1] >>> PR: [2] >>> Upsource: [3] >>>=20 >>> Questions to discuss: >>> 1) There is no analogue for inspections RedundantSuppression >>>=20 >>> and >>>=20 >>> SizeReplaceableByIsEmpty (all code style checks [5]). Propose >>>=20 >>> to merge >>>=20 >>> 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 >>>=20 >>> and >>>=20 >>> propose to disable it as not working. >>>=20 >>>=20 >>> [1] https://issues.apache.org/jira/browse/IGNITE-11277 >>> [2] https://github.com/apache/ignite/pull/6119 >>> [3] >>>=20 >>> https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018 >>>=20 >>> [4] >>>=20 >>> = https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=3D1677= 1200&page=3Dcom.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabp= anel#comment-16771200 >>>=20 >>> [5] http://checkstyle.sourceforge.net/checks.html >>>=20 >>> 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 < >>>=20 >>> vololo100@gmail.com> wrote: >>>=20 >>>=20 >>> Nikolay, >>>=20 >>> All community members are forced to follow code style. >>>=20 >>> It's harder to achieve it with dedicated suite. >>>=20 >>> Why it is easier to follow code style with use of maven >>>=20 >>> checkstyle >>>=20 >>> plugin? Is it integrated into IDEA out of box? As I got it >>>=20 >>> additional >>>=20 >>> IDEA plugin is needed as well. Who will enforce everybody to >>>=20 >>> install >>>=20 >>> it? >>>=20 >>> Also, as I see a common good practice today is using TC Bot >>>=20 >>> visa. Visa >>>=20 >>> includes result from running inspections job. >>>=20 >>> =D1=87=D1=82, 14 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 = 16:08, Nikolay Izhikov < >>>=20 >>> nizhikov@apache.org>: >>>=20 >>>=20 >>> Ivan, >>>=20 >>> Could you please outline the benefits you see of failing >>>=20 >>> compilation and >>>=20 >>> skipping tests execution if inspections detect a problem? >>>=20 >>> All community members are forced to follow code style. >>> It's harder to achieve it with dedicated suite. >>>=20 >>>=20 >>> =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 < >>>=20 >>> vololo100@gmail.com>: >>>=20 >>>=20 >>> Nikolay, >>>=20 >>> Should the community spend TC resources for prototype? >>>=20 >>> Why not? I think it is not bad idea to run all tests >>>=20 >>> against some >>>=20 >>> changes into core classes. If I have a clever idea which >>>=20 >>> is easy to >>>=20 >>> test drive I can do couple of prototype-test iterations. >>>=20 >>> If tests >>>=20 >>> shows me that everything is bad then the idea was not so >>>=20 >>> clever and >>>=20 >>> easy. But if I was lucky then I should discuss the idea >>>=20 >>> with other >>>=20 >>> Igniters. I think it is the cheapest way to check the >>>=20 >>> idea because the >>>=20 >>> check is fully automated. Requiring a human feedback is >>>=20 >>> much more >>>=20 >>> expensive in my opinion. >>>=20 >>> But, If our code style is not convinient for every day >>>=20 >>> coding for many >>>=20 >>> contributors, should you initiate discussion to change >>>=20 >>> it? >>>=20 >>> Generally I am fine with our codestyle requirements. >>>=20 >>> Also, I would like to keep a focus on the subject. Could >>>=20 >>> you please >>>=20 >>> outline the benefits you see of failing compilation and >>>=20 >>> skipping tests >>>=20 >>> execution if inspections detect a problem? >>>=20 >>> =D1=87=D1=82, 14 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 = 14:14, Nikolay Izhikov < >>>=20 >>> nizhikov@apache.org>: >>>=20 >>>=20 >>> Hello, Ivan. >>>=20 >>> Requirements for a prototype code are not the same >>>=20 >>> as for a patch ready >>>=20 >>> to merge >>>=20 >>> True. >>>=20 >>> I do not see much need in writing good javadocs for >>>=20 >>> prototype. >>>=20 >>>=20 >>> We, as a community, can't force you to do it. >>>=20 >>> Why should I stub it to be able run any build on TC? >>>=20 >>>=20 >>> Should the community spend TC resources for prototype? >>> You always can check tests for your prototype locally. >>>=20 >>> And when it's ready, at least from code style point of >>>=20 >>> view run it on TC. >>>=20 >>>=20 >>> I, personally, always try to follow project code >>>=20 >>> style, even for >>>=20 >>> prototypes. >>>=20 >>> But, If our code style is not convinient for every day >>>=20 >>> coding for many >>>=20 >>> contributors, should you initiate discussion to change >>>=20 >>> it? >>>=20 >>>=20 >>>=20 >>> =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 < >>>=20 >>> vololo100@gmail.com>: >>>=20 >>>=20 >>> Maxim, >>>=20 >>> Oh, my poor tabs.. Joke. >>>=20 >>> I am totally ok with currently enabled checks. But I >>>=20 >>> am mostly >>>=20 >>> concerned about a general approach. I would like to >>>=20 >>> outline one thing. >>>=20 >>> Requirements for a prototype code are not the same >>>=20 >>> as for a patch >>>=20 >>> ready to merge (see a little bit more in the end of >>>=20 >>> that message). >>>=20 >>>=20 >>> We have a document defining code style which every >>>=20 >>> contributor should >>>=20 >>> follow [1]. And many points can be checked >>>=20 >>> automatically. Personally, >>>=20 >>> I do not see much need in writing good javadocs for >>>=20 >>> prototype. Why >>>=20 >>> should I stub it to be able run any build on TC? >>>=20 >>> Also, we a have a review process which should be >>>=20 >>> applied to every >>>=20 >>> patch. Partially it is described in [2]. And due to >>>=20 >>> this process every >>>=20 >>> patch should not introduce new failures on TC. So, >>>=20 >>> the patch should >>>=20 >>> not be merged if inspections failed. >>>=20 >>> P.S. Something more about prototypes and production >>>=20 >>> code. There is a >>>=20 >>> common bad practice in software engineering. It is >>>=20 >>> turning prototypes >>>=20 >>> into production code. Often it is much faster to >>>=20 >>> create a prototype by >>>=20 >>> price of violating some rules of writing "clean >>>=20 >>> code". And often >>>=20 >>> prototype after successful piloting is turned into >>>=20 >>> production code. >>>=20 >>> And it is very easy in practice to keep some pieces >>>=20 >>> of initially >>>=20 >>> "dirty" prototype code. I believe human factor plays >>>=20 >>> a great role >>>=20 >>> here. How should it be done right then? In my >>>=20 >>> opinion good production >>>=20 >>> code should be designed as "good production code" >>>=20 >>> from the beginning. >>>=20 >>> So, only ideas are taken from the prototype and a >>>=20 >>> code is fully >>>=20 >>> rewritten. >>>=20 >>> [1] >>>=20 >>>=20 >>> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines >>>=20 >>> [2] >>>=20 >>>=20 >>> https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist >>>=20 >>>=20 >>> =D1=81=D1=80, 13 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 = 15:05, Maxim Muzafarov < >>>=20 >>> maxmuzaf@gmail.com>: >>>=20 >>>=20 >>> Ivan, >>>=20 >>> As the first implementation of this addition, I'd >>>=20 >>> prefer to make it >>>=20 >>> working like _Licenses Headers_ suite check. It >>>=20 >>> will fail when some >>>=20 >>> of >>>=20 >>> the code style checks violated. Moreover, these >>>=20 >>> licenses header >>>=20 >>> checks >>>=20 >>> can be included in the checkstyle plugin >>>=20 >>> configuration. >>>=20 >>>=20 >>> In general, I'd prefer to have a compilation fail >>>=20 >>> error with code >>>=20 >>> style checks and after we will get a stable >>>=20 >>> checkstyle suite I >>>=20 >>> propose >>>=20 >>> to change it in a "compilation error" way. If we >>>=20 >>> are talking about >>>=20 >>> the >>>=20 >>> coding style convenient for most of the community >>>=20 >>> members I see no >>>=20 >>> difference with coding sketches or >>>=20 >>> production-ready branches equally. >>>=20 >>> Indeed, no one will be against unused imports [or >>>=20 >>> spaces instead of >>>=20 >>> tabs :-) ] in their PRs or prototypes, right? (for >>>=20 >>> instance, it can >>>=20 >>> be >>>=20 >>> automatically removed by IDE at commit phase). >>>=20 >>> 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 >>>=20 >>> final ..) >>>=20 >>> - redundunt suppersion checks >>> - spaces insted of tabs. >>>=20 >>> Are you really what to violate these checks in >>>=20 >>> your sketches? Hope >>>=20 >>> not >>>=20 >>> :-) >>>=20 >>>=20 >>> On Wed, 13 Feb 2019 at 10:25, Nikolay Izhikov < >>>=20 >>> nizhikov@apache.org> >>>=20 >>> wrote: >>>=20 >>>=20 >>> Actually, I dont see anything wrong with failing >>>=20 >>> *compilation* >>>=20 >>> task. >>>=20 >>>=20 >>> I think one should use project code style for >>>=20 >>> everyday coding, not >>>=20 >>> only for >>>=20 >>> ready-to-merge PRs. >>>=20 >>> If we cant use code style for everyday coding, >>>=20 >>> we should change the >>>=20 >>> codestyle. >>>=20 >>> What do you think? >>>=20 >>> =D1=81=D1=80, 13 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3., 10:11 Petr = Ivanov >>>=20 >>> mr.weider@gmail.com: >>>=20 >>>=20 >>> I guess that was about failing build >>>=20 >>> configuration with >>>=20 >>> Checkstype, >>>=20 >>> not >>>=20 >>> compilation build itself. >>>=20 >>> 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 < >>>=20 >>> vololo100@gmail.com> >>>=20 >>> wrote: >>>=20 >>>=20 >>> Folks, >>>=20 >>> Are you going to fail job compiling Ignite >>>=20 >>> sources [1] if some >>>=20 >>> inspection found a problem? Can we avoid it? >>>=20 >>> It is quite common >>>=20 >>> pattern to start some feature implementation >>>=20 >>> with making a >>>=20 >>> sketch >>>=20 >>> and >>>=20 >>> running tests against it. I found it >>>=20 >>> convenient to skip some >>>=20 >>> style >>>=20 >>> requirements for such sketches (e.g. well >>>=20 >>> formed javadocs). >>>=20 >>>=20 >>> [1] >>>=20 >>>=20 >>>=20 >>>=20 >>> = https://ci.ignite.apache.org/viewType.html?buildTypeId=3DIgniteTests24Java= 8_BuildApacheIgnite >>>=20 >>>=20 >>> =D0=BF=D0=BD, 11 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 = 11:38, Nikolay >>>=20 >>> Izhikov < >>>=20 >>> nizhikov@apache.org >>>=20 >>> : >>>=20 >>>=20 >>> Petr, we should have 1 configuration for >>>=20 >>> project, may be 1 >>>=20 >>> configuration >>>=20 >>> per programming language. >>>=20 >>> =D0=BF=D0=BD, 11 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3., 11:33 Petr = Ivanov >>>=20 >>> mr.weider@gmail.com: >>>=20 >>>=20 >>> I was asking about how many build >>>=20 >>> configuration is intended? >>>=20 >>> One >>>=20 >>> for >>>=20 >>> all >>>=20 >>> and multiple per module? >>>=20 >>> With IDEA inspections it was going to be >>>=20 >>> build configuration >>>=20 >>> per >>>=20 >>> module. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 11 Feb 2019, at 11:24, Nikolay Izhikov >>>=20 >>> < >>>=20 >>> nizhikov@apache.org> >>>=20 >>> wrote: >>>=20 >>>=20 >>> Hello, Petr. >>>=20 >>> Are you saying that we have not single >>>=20 >>> build task? And each >>>=20 >>> module >>>=20 >>> builds >>>=20 >>> when it required? If yes, then I propose >>>=20 >>> to create a task >>>=20 >>> like >>>=20 >>> "Licence >>>=20 >>> check" which will be run for every patch. >>>=20 >>> My point is that violation of codestyle >>>=20 >>> should be treated as >>>=20 >>> hard as >>>=20 >>> compile error. >>>=20 >>> =D0=BF=D0=BD, 11 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3., 11:16 Petr = Ivanov >>>=20 >>> mr.weider@gmail.com >>>=20 >>> : >>>=20 >>>=20 >>> Is build configuration Inspections >>>=20 >>> [Core] meant to >>>=20 >>> transform >>>=20 >>> into >>>=20 >>> single >>>=20 >>> all-modules check build configuration >>>=20 >>> (without module >>>=20 >>> subdivision)? >>>=20 >>>=20 >>>=20 >>> On 11 Feb 2019, at 11:02, Nikolay >>>=20 >>> Izhikov < >>>=20 >>> nizhikov@apache.org> >>>=20 >>> wrote: >>>=20 >>>=20 >>> Hello, Maxim. >>>=20 >>> +1 from me for migrating to checkstyle. >>>=20 >>> Oleg, there is plugin for IDEA with >>>=20 >>> 2mln downloads - >>>=20 >>>=20 >>> https://plugins.jetbrains.com/plugin/1065-checkstyle-idea >>>=20 >>>=20 >>> I propose do the following: >>>=20 >>> 1. Migrate current checks to checkstyle. >>> 2. Apply checks to all Ignite modules. >>>=20 >>> Currently, only >>>=20 >>> core >>>=20 >>> module >>>=20 >>> are >>>=20 >>> checked. >>> I will review and commit this patch, or >>>=20 >>> do it by my own. >>>=20 >>>=20 >>> 3. Include code style checks to "Build >>>=20 >>> Apache Ignite" >>>=20 >>> suite. >>>=20 >>> Ignite >>>=20 >>> has >>>=20 >>> to >>>=20 >>> fail to build if patch violates >>>=20 >>> codestyle. >>>=20 >>>=20 >>> =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 >>>=20 >>> =D0=98=D0=B2=D0=B0=D0=BD < >>>=20 >>> vololo100@gmail.com>: >>>=20 >>>=20 >>> Hi, >>>=20 >>> I also think that some warning from >>>=20 >>> IDEA that some code >>>=20 >>> style rule >>>=20 >>> is >>>=20 >>> violated is a must-have. >>>=20 >>> =D0=B2=D1=81, 10 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 = 01:58, >>>=20 >>> oignatenko < >>>=20 >>> oignatenko@gridgain.com >>>=20 >>> : >>>=20 >>>=20 >>> Hi Maxim, >>>=20 >>> I believe that whatever style checks >>>=20 >>> we establish at >>>=20 >>> Teamcity, we >>>=20 >>> better >>>=20 >>> take care of making it easy for >>>=20 >>> developers to find and >>>=20 >>> fix >>>=20 >>> violations >>>=20 >>> in >>>=20 >>> their typical dev environment (for >>>=20 >>> Ignite this means, in >>>=20 >>> IDEA). I >>>=20 >>> think >>>=20 >>> it >>>=20 >>> is important that developers can >>>=20 >>> maintain required style >>>=20 >>> with >>>=20 >>> minimal >>>=20 >>> effort >>>=20 >>> on their side. >>>=20 >>> If above is doable then I am 200% for >>>=20 >>> migrating our >>>=20 >>> Teamcity >>>=20 >>> inspections >>>=20 >>> to >>>=20 >>> checkstyle / maven. >>>=20 >>> This is because I am very >>>=20 >>> disappointed observing how it >>>=20 >>> stays >>>=20 >>> broken >>>=20 >>> for >>>=20 >>> so >>>=20 >>> long. And worst of all, even when >>>=20 >>> (if) it is fixed, I >>>=20 >>> feel >>>=20 >>> we will >>>=20 >>> always be >>>=20 >>> at risk that it breaks again and that >>>=20 >>> we will have to >>>=20 >>> again >>>=20 >>> wait >>>=20 >>> for >>>=20 >>> months >>>=20 >>> for it to be fixed. >>>=20 >>> This is such a stark contrast with my >>>=20 >>> experience >>>=20 >>> regarding >>>=20 >>> checkstyle >>>=20 >>> based >>>=20 >>> inspections. These just work and you >>>=20 >>> just never fear >>>=20 >>> that >>>=20 >>> it is >>>=20 >>> going >>>=20 >>> to >>>=20 >>> break for some obscure reason, this >>>=20 >>> is so much better >>>=20 >>> than >>>=20 >>> what I >>>=20 >>> observe >>>=20 >>> now. >>>=20 >>> One suggestion in case if we pick >>>=20 >>> checkstyle - I >>>=20 >>> recommend >>>=20 >>> keeping >>>=20 >>> its >>>=20 >>> config file somewhere in the project >>>=20 >>> under version >>>=20 >>> control. >>>=20 >>> I >>>=20 >>> used to >>>=20 >>> maintain such a shared style config >>>=20 >>> at one of past jobs >>>=20 >>> and >>>=20 >>> after >>>=20 >>> some >>>=20 >>> experimenting it turned out most >>>=20 >>> convenient to have it >>>=20 >>> this >>>=20 >>> way - >>>=20 >>> so >>>=20 >>> that >>>=20 >>> developers could easily assess and >>>=20 >>> discuss style >>>=20 >>> settings >>>=20 >>> and keep >>>=20 >>> track >>>=20 >>> of >>>=20 >>> changes in these. (note how Kafka >>>=20 >>> folks from your link >>>=20 >>> [5] >>>=20 >>> appear >>>=20 >>> to >>>=20 >>> be >>>=20 >>> doing it this way) >>>=20 >>> regards, Oleg >>>=20 >>>=20 >>> Mmuzaf wrote >>>=20 >>> Igniters, >>>=20 >>> I've found that some of the >>>=20 >>> community members have >>>=20 >>> faced >>>=20 >>> with >>>=20 >>> `[Inspections] Core suite [1]` is >>>=20 >>> not working well >>>=20 >>> enough >>>=20 >>> on TC. >>>=20 >>> The >>>=20 >>> suite has a `FAILED` status for more >>>=20 >>> than 2 months due >>>=20 >>> to >>>=20 >>> some >>>=20 >>> issues >>>=20 >>> in TeamCity application [2]. Current >>>=20 >>> suite behaviour >>>=20 >>> confuses not >>>=20 >>> only >>>=20 >>> new contributors but also other >>>=20 >>> community members. >>>=20 >>> Moreover, this >>>=20 >>> suite is no longer checks rules we >>>=20 >>> previously >>>=20 >>> configured. >>>=20 >>> For >>>=20 >>> instance, in the master branch, I've >>>=20 >>> found 11 `Unused >>>=20 >>> imports` >>>=20 >>> which >>>=20 >>> should have been caught earlier >>>=20 >>> (e.g. for >>>=20 >>> {{IgniteCachePutAllRestartTest} [3]). >>>=20 >>> I think we should make the next step >>>=20 >>> to enable an >>>=20 >>> automatic code >>>=20 >>> style >>>=20 >>> checks. As an example, we can >>>=20 >>> consider the Apache Kafka >>>=20 >>> code >>>=20 >>> style >>>=20 >>> [5] >>>=20 >>> way and configure for the Ignite >>>=20 >>> project a >>>=20 >>> maven-checkstyle-plugin >>>=20 >>> with its own maven profile and run >>>=20 >>> it simultaneously >>>=20 >>> with >>>=20 >>> other >>>=20 >>> TC. >>>=20 >>> We >>>=20 >>> can also enable the previously >>>=20 >>> configured inspection >>>=20 >>> rules, so no >>>=20 >>> coding style violations will be >>>=20 >>> missed. >>>=20 >>>=20 >>> I see some advantages of using a >>>=20 >>> maven plugin: >>>=20 >>> - an IDE agnostic way for code checks >>> - can be used with different CI and >>>=20 >>> build tools >>>=20 >>> (Jenkins, >>>=20 >>> TC) >>>=20 >>> - executable from the command line >>> - the entry single point to >>>=20 >>> configure new rules >>>=20 >>>=20 >>> I've created the ticket [4] and will >>>=20 >>> prepare PR for it. >>>=20 >>>=20 >>> WDYT? >>>=20 >>> [1] >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> = https://ci.ignite.apache.org/viewType.html?buildTypeId=3DIgniteTests24Java= 8_InspectionsCore&branch_IgniteTests24Java8=3D%3Cdefault%3E&tab=3DbuildTyp= eStatusDiv >>>=20 >>> [2] >>>=20 >>> https://youtrack.jetbrains.com/issue/TW-58504 >>>=20 >>> [3] >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> = https://github.com/apache/ignite/blob/master/modules/core/src/test/java/or= g/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.jav= a#L29 >>>=20 >>> [4] >>>=20 >>> https://issues.apache.org/jira/browse/IGNITE-11277 >>>=20 >>> [5] >>>=20 >>> https://github.com/apache/kafka/tree/trunk/checkstyle >>>=20 >>>=20 >>> On Fri, 21 Dec 2018 at 16:03, Petr >>>=20 >>> Ivanov < >>>=20 >>>=20 >>> mr.weider@ >>>=20 >>>=20 >>> > wrote: >>>=20 >>>=20 >>> It seems there is bug in latest >>>=20 >>> 2018.2 TeamCity >>>=20 >>> Bug is filed [1] >>>=20 >>>=20 >>> [1] >>>=20 >>> https://youtrack.jetbrains.com/issue/TW-58504 >>>=20 >>>=20 >>> On 19 Dec 2018, at 11:31, Petr >>>=20 >>> Ivanov < >>>=20 >>>=20 >>> mr.weider@ >>>=20 >>>=20 >>> > wrote: >>>=20 >>>=20 >>> Investigating problem, stand by. >>>=20 >>>=20 >>> On 18 Dec 2018, at 19:41, Dmitriy >>>=20 >>> Pavlov < >>>=20 >>>=20 >>> dpavlov@ >>>=20 >>>=20 >>> > wrote: >>>=20 >>>=20 >>> Both patches were applied. Maxim, >>>=20 >>> thank you! >>>=20 >>>=20 >>> What about 1. An `Unexpected >>>=20 >>> error during build >>>=20 >>> messages >>>=20 >>> processing in >>>=20 >>> TeamCity`, what can we do as the >>>=20 >>> next step to fix >>>=20 >>> it? >>>=20 >>>=20 >>> Sincerely, >>> Dmitriy Pavlov >>> [cut] >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Sent from: >>>=20 >>>=20 >>> http://apache-ignite-developers.2346864.n4.nabble.com/ >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Best regards, >>> Ivan Pavlukhin >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Best regards, >>> Ivan Pavlukhin >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Best regards, >>> Ivan Pavlukhin >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Best regards, >>> Ivan Pavlukhin >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Best regards, >>> Ivan Pavlukhin >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Best regards, >>> Ivan Pavlukhin >>>=20 >>>=20 >>> -- >>> -- >>> Maxim Muzafarov >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Best regards, >>> Ivan Pavlukhin >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Best regards, >>> Ivan Pavlukhin >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Best regards, >>> Ivan Pavlukhin >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Best Regards, Vyacheslav D. >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Best Regards, Vyacheslav D. >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Best Regards, Vyacheslav D. >>>=20 >>>=20 >>=20 >>=20 >> --=20 >> Best Regards, Vyacheslav D. >=20