Re: Code inspection

[Maxim Muzafarov <ma...@gmail.com>]

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 community members. Moreover, this
suite is no longer checks rules we previously 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 consider the Apache Kafka code style [5]
way and configure for the Ignite project a maven-checkstyle-plugin
with its own maven profile and run it simultaneously with other TC. We
can also enable the previously configured inspection rules, so no
coding style violations will be missed.

I see some advantages of using a maven plugin:
- an IDE agnostic way for code checks
- can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
[2] https://youtrack.jetbrains.com/issue/TW-58504
[3]https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
[4] https://issues.apache.org/jira/browse/IGNITE-11277
[5] https://github.com/apache/kafka/tree/trunk/checkstyle

On Fri, 21 Dec 2018 at 16:03, Petr Ivanov <mr...@gmail.com> wrote:
>
> It seems there is bug in latest 2018.2 TeamCity
> Bug is filed [1]
>
>
> [1] https://youtrack.jetbrains.com/issue/TW-58504
>
> > On 19 Dec 2018, at 11:31, Petr Ivanov <mr...@gmail.com> wrote:
> >
> > Investigating problem, stand by.
> >
> >
> >> On 18 Dec 2018, at 19:41, Dmitriy Pavlov <dp...@apache.org> 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 next step to fix it?
> >>
> >> Sincerely,
> >> Dmitriy Pavlov
> >>
> >> пн, 17 дек. 2018 г. в 18:31, Andrey Mashenkov <an...@gmail.com>:
> >>
> >>> Maxim,
> >>>
> >>> Looks ok. Let's apply IGNITE-10682.
> >>>
> >>> All,
> >>>
> >>> Also, I'd like to publish idea.logs into artefacts by default.
> >>> This will give us more details for investigation in future if any failure
> >>> will occurs.
> >>> It will costs 1-10 kB.
> >>>
> >>> On Mon, Dec 17, 2018 at 3:21 PM Maxim Muzafarov <ma...@gmail.com>
> >>> wrote:
> >>>
> >>>> Dmitry,
> >>>>
> >>>> It seems to me that we have two independent issues here.
> >>>> 1. An `Unexpected error during build messages processing in TeamCity`
> >>>> error message which is related to TC agent configuration. Suppose,
> >>>> server.log will provide us more details about it. I have to access
> >>>> there.
> >>>> 2. A new set of inspection rules was introduced in 2018+ IntelliJ IDEA
> >>>> and they should be disabled in our ignite_inspections_teamcity.xml
> >>>> configuration file. They are not fixed in the Apache Ignite project
> >>>> code yet. I've prepared the issue [1] for it. Please, take a look.
> >>>>
> >>>>
> >>>> Andrey,
> >>>>
> >>>> I've fixed disabled plugins file according to your suggestions. The
> >>>> issue [2] is ready. I've re-run `Excluded [Inspections] Core Debug`
> >>>> suite and the log details show me that now only 3 plugins are enabled:
> >>>> IDEA CORE, Maven Integration, Properties Support. It seems to me that
> >>>> it's correct.
> >>>>
> >>>> [1] https://issues.apache.org/jira/browse/IGNITE-10709
> >>>> [2] https://issues.apache.org/jira/browse/IGNITE-10682
> >>>>
> >>>> On Sat, 15 Dec 2018 at 15:22, Dmitriy Pavlov <dp...@apache.org> wrote:
> >>>>>
> >>>>> Folks,
> >>>>>
> >>>>> There is a strange error on TC
> >>>>>
> >>>>
> >>> https://ci.ignite.apache.org/viewLog.html?buildId=2556875&buildTypeId=IgniteTests24Java8_InspectionsCore
> >>>>>
> >>>>> It appeared after TC update to the latest version.
> >>>>>
> >>>>> Sincerely,
> >>>>> Dmitry Pavlov
> >>>>>
> >>>>> пт, 14 дек. 2018 г. в 16:09, Andrey Mashenkov <
> >>>> andrey.mashenkov@gmail.com>:
> >>>>>
> >>>>>> Maxim,
> >>>>>>
> >>>>>> PR is incomplete. Some plugins should be disabled with different
> >>>> id\name.
> >>>>>> Maven plugin shouldn't be disabled as Idea Inspector use it to use
> >>>> Ignite
> >>>>>> project pom file.
> >>>>>>
> >>>>>> Please, find details in ticket.
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Dec 14, 2018 at 12:00 PM Andrey Mashenkov <
> >>>>>> andrey.mashenkov@gmail.com> wrote:
> >>>>>>
> >>>>>>> Maxim,
> >>>>>>>
> >>>>>>> Thanks, I'll check PR and let you know about results.
> >>>>>>>
> >>>>>>> For now, Inspections task execution time looks much better (15-22
> >>>> min),
> >>>>>>> but fluctuation is still noticeable.
> >>>>>>>
> >>>>>>> On Fri, Dec 14, 2018 at 11:13 AM Maxim Muzafarov <
> >>> maxmuzaf@gmail.com
> >>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Andrey,
> >>>>>>>>
> >>>>>>>> Thanks! I've consulted with the IntelliJ IDEA source code and
> >>> found
> >>>>>>>> how this disabled plugins file should look like. I've created a
> >>> new
> >>>>>>>> issue [1] and prepared PR [2] with the set of disabled plugins
> >>>> (maybe
> >>>>>>>> not complete set). I don't have access to change corresponding
> >>>>>>>> `~Excluded [Inspections] Core Debug` test suite properties.
> >>>>>>>> Can we test this PR?
> >>>>>>>>
> >>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-10682
> >>>>>>>> [2] https://github.com/apache/ignite/pull/5666
> >>>>>>>> On Thu, 13 Dec 2018 at 17:35, Andrey Mashenkov
> >>>>>>>> <an...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> Maxim,
> >>>>>>>>>
> >>>>>>>>> Idea has a file in config directory
> >>> ./config/disabled_plugins.txt
> >>>> ,
> >>>>>> you
> >>>>>>>> can easily find it at you local machine.
> >>>>>>>>> Teamcity Inspections runner has an option "Disabled plugins"
> >>> where
> >>>>>>>> disabled_plugins.txt file content can be set.
> >>>>>>>>>
> >>>>>>>>> So, looks like we can disable useless plugins.
> >>>>>>>>> But I'm not expert and can't suggest changes we can safely
> >>> apply.
> >>>>>>>>>
> >>>>>>>>> On Thu, Dec 13, 2018 at 4:59 PM Maxim Muzafarov <
> >>>> maxmuzaf@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Andrey,
> >>>>>>>>>>
> >>>>>>>>>> Thank you for solving this issue with GC pauses! I've checked
> >>> the
> >>>>>>>>>> given report. The inspections configuration is correct, but it
> >>>> seems
> >>>>>>>>>> to me that we have enabled by default rules of included plugins
> >>>> (for
> >>>>>>>>>> instance, KotlinInternalInJava in the report is enabled).
> >>>>>>>>>>
> >>>>>>>>>> Can you share more details about `disable plugin` option you
> >>>> found?
> >>>>>>>>>>
> >>>>>>>>>> I see that idea instance starts with the default
> >>>> -Didea.plugins.path
> >>>>>>>>>> system property, can we change it so the plugins will be not
> >>>> loaded
> >>>>>> by
> >>>>>>>>>> default?
> >>>>>>>>>> On Thu, 13 Dec 2018 at 15:45, Andrey Mashenkov
> >>>>>>>>>> <an...@gmail.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Maxim,
> >>>>>>>>>>>
> >>>>>>>>>>> It looks like we can't make logs more verbose due to possible
> >>>> bug,
> >>>>>>>> I've create a ticket in Jetbrains Jira [1].
> >>>>>>>>>>> We can just publish idea logs in artefacts as suggested in
> >>> this
> >>>>>>>> manual [2].
> >>>>>>>>>>>
> >>>>>>>>>>> For now, Inspections logs looks like this one [3].
> >>>>>>>>>>> Also, would you please to take a look at inspection report
> >>> and
> >>>>>> check
> >>>>>>>> if we missed smth and there are any unwanted inspection turned on.
> >>>>>>>>>>>
> >>>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58422
> >>>>>>>>>>> [2]
> >>>>>>>>
> >>>>>>
> >>>>
> >>> https://confluence.jetbrains.com/display/TCD10/Reporting+Issues#ReportingIssues-IntelliJIDEAInspections
> >>>>>>>>>>> [3]
> >>>>>>>>
> >>>>>>
> >>>>
> >>> https://ci.ignite.apache.org/viewLog.html?buildId=2538111&buildTypeId=IgniteTests24Java8_ExcludedInspections2&tab=artifacts
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Dec 13, 2018 at 3:19 PM Dmitriy Pavlov <
> >>>> dpavlov@apache.org
> >>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Maxim M, do you know if we can disable inspections by
> >>>> wildcard?
> >>>>>> E.g.
> >>>>>>>>>>>> Android* ?
> >>>>>>>>>>>>
> >>>>>>>>>>>> чт, 13 дек. 2018 г. в 14:59, Andrey Mashenkov <
> >>>>>>>> andrey.mashenkov@gmail.com>:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Fixed memory issues with increasing heap size and forcing
> >>>> G1GC.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Do we need all these plugins loaded for inspections?
> >>>>>>>>>>>>> I've found a 'disable plugin' option in TC Inspections
> >>> build
> >>>>>>>> configuration,
> >>>>>>>>>>>>> but it is unclear how to disable plugin correctly.
> >>>>>>>>>>>>> Can someone take over this?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> 46 plugins initialized in 1031 ms
> >>>>>>>>>>>>>> 2018-12-13 10:55:24,875 [ 1342] INFO -
> >>>>>>>> llij.ide.plugins.PluginManager -
> >>>>>>>>>>>>>> Loaded bundled plugins: Android Support (10.2.3), Ant
> >>>> Support
> >>>>>>>> (1.0), CSS
> >>>>>>>>>>>>>> Support (172.4574.11), Database Tools and SQL
> >>>> (172.4574.11),
> >>>>>>>> Eclipse
> >>>>>>>>>>>>>> Integration (3.0), FreeMarker support (1.0), GWT Support
> >>>>>> (1.0),
> >>>>>>>> Gradle
> >>>>>>>>>>>>>> (172.4574.11), Groovy (9.0), Guice (8.0), HTML Tools
> >>>> (2.0),
> >>>>>>>> Hibernate
> >>>>>>>>>>>>>> Support (1.0), I18n for Java (172.4574.11), IDEA CORE
> >>>>>>>> (172.4574.11),
> >>>>>>>>>>>>>> IntelliLang (8.0), JBoss Seam Support (1.0), JUnit
> >>> (1.0),
> >>>> Java
> >>>>>>>> EE: Bean
> >>>>>>>>>>>>>> Validation Support (1.1), Java EE: Contexts and
> >>> Dependency
> >>>>>>>> Injection
> >>>>>>>>>>>>> (1.1),
> >>>>>>>>>>>>>> Java EE: EJB, JPA, Servlets (1.0), Java EE: Java Server
> >>>> Faces
> >>>>>>>> (2.2.X.),
> >>>>>>>>>>>>>> Java EE: Web Services (JAX-WS) (1.9), Java Server Pages
> >>>> (JSP)
> >>>>>>>> Integration
> >>>>>>>>>>>>>> (1.0), JavaScript Support (1.0), Kotlin
> >>>>>>>> (1.1.4-release-IJ2017.2-3), Maven
> >>>>>>>>>>>>>> Integration (172.4574.11), Persistence Frameworks
> >>> Support
> >>>>>>>> (1.0), Plugin
> >>>>>>>>>>>>>> DevKit (1.0), Properties Support (172.4574.11),
> >>> QuirksMode
> >>>>>>>> (172.4574.11),
> >>>>>>>>>>>>>> Spring AOP/@AspectJ (1.0), Spring Batch (1.0), Spring
> >>> Data
> >>>>>>>> (1.0), Spring
> >>>>>>>>>>>>>> Integration Patterns (1.0), Spring Security (1.0),
> >>> Spring
> >>>>>>>> Support (1.0),
> >>>>>>>>>>>>>> Spring Web Flow (1.0), Spring Web Services (1.0), Struts
> >>>> 1.x
> >>>>>>>> (2.0),
> >>>>>>>>>>>>> Struts
> >>>>>>>>>>>>>> 2 (1.0), TestNG-J (8.0), UI Designer (172.4574.11),
> >>>> Velocity
> >>>>>>>> support
> >>>>>>>>>>>>> (1.0),
> >>>>>>>>>>>>>> W3C Validators (2.0), WebLogic Integration (1.0),
> >>>> XPathView +
> >>>>>>>> XSLT
> >>>>>>>>>>>>> Support
> >>>>>>>>>>>>>> (4)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Kotlin plugins fails to start, let's disable it.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2018-12-13 10:55:27,623 [   4090]   INFO -
> >>>>>>>>>>>>> il.indexing.FileBasedIndexImpl - Rebuild requested for
> >>> index
> >>>>>>>>>>>>>
> >>>> org.jetbrains.kotlin.idea.versions.KotlinJvmMetadataVersionIndex
> >>>>>>>>>>>>>> java.lang.Throwable
> >>>>>>>>>>>>>>     at
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>> com.intellij.util.indexing.FileBasedIndex.requestRebuild(FileBasedIndex.java:68)
> >>>>>>>>>>>>>>     at
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>> org.jetbrains.kotlin.idea.versions.KotlinUpdatePluginComponent.initComponent(KotlinUpdatePluginComponent.kt:54)
> >>>>>>>>>>>>>>     at
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>> com.intellij.openapi.components.impl.ComponentManagerImpl$ComponentConfigComponentAdapter.getComponentInstance(ComponentManagerImpl.java:492)
> >>>>>>>>>>>>>>     at
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>> com.intellij.openapi.components.impl.ComponentManagerImpl.createComponents(ComponentManagerImpl.java:118)
> >>>>>>>>>>>>>>     at
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>> com.intellij.openapi.application.impl.ApplicationImpl.a(ApplicationImpl.java:462)
> >>>>>>>>>>>>>>     at
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>> com.intellij.openapi.application.impl.ApplicationImpl.createComponents(ApplicationImpl.java:466)
> >>>>>>>>>>>>>>     at
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>> com.intellij.openapi.components.impl.ComponentManagerImpl.init(ComponentManagerImpl.java:102)
> >>>>>>>>>>>>>>     at
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>> com.intellij.openapi.application.impl.ApplicationImpl.load(ApplicationImpl.java:421)
> >>>>>>>>>>>>>>     at
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>> com.intellij.openapi.application.impl.ApplicationImpl.load(ApplicationImpl.java:407)
> >>>>>>>>>>>>>>     at
> >>>>>>>> com.intellij.idea.IdeaApplication.run(IdeaApplication.java:203)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Thu, Dec 13, 2018 at 1:45 PM Dmitriy Pavlov <
> >>>>>>>> dpavlov@apache.org> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Sure, let's apply. I hope all TC agents may handle 4G
> >>>> heap.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> чт, 13 дек. 2018 г. в 12:54, Andrey Mashenkov <
> >>>>>>>>>>>>> andrey.mashenkov@gmail.com
> >>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Guys,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I've just creates a copy of Inspections TC build task
> >>>> with
> >>>>>> GC
> >>>>>>>> logs
> >>>>>>>>>>>>> turned
> >>>>>>>>>>>>>>> on to check if there is any issues
> >>>>>>>>>>>>>>> and found Inspections task spent too much time in STW
> >>>> due to
> >>>>>>>> long Full
> >>>>>>>>>>>>> GC
> >>>>>>>>>>>>>>> pauses.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I've tried to increase Xmx up to 4Gb and use G1GC got
> >>> 2+
> >>>>>>>> times better
> >>>>>>>>>>>>>>> execution time down to ~15 min (~17 for 2G heap).
> >>>>>>>>>>>>>>> Increasing heap size only is not very helpful as it
> >>> just
> >>>>>>>> postpone Full
> >>>>>>>>>>>>> GC
> >>>>>>>>>>>>>>> issues, but changing GC to G1GC gives noticeable
> >>> result.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Let's apply this optimization.
> >>>>>>>>>>>>>>> Thoughts?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Sun, Dec 9, 2018 at 12:43 PM Vyacheslav Daradur <
> >>>>>>>>>>>>> daradurvs@gmail.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi, Maxim, Nikolay, I have the following questions
> >>>>>> regarding
> >>>>>>>>>>>>>> inspections:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Should 'gnite_inspections_teamcity.xml' been
> >>> imported
> >>>> into
> >>>>>>>> IDEA,
> >>>>>>>>>>>>> since
> >>>>>>>>>>>>>>>> 'ignite_inspections.xml' has been removed in actual
> >>>>>> master?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Also, I've faced mismatching: if I use
> >>>>>>>>>>>>>>>> '@SuppressWarnings("ErrorNotRethrown")' in code,
> >>> then
> >>>> this
> >>>>>>>> will be
> >>>>>>>>>>>>>>>> marked on TC as "Redundant suppression". If I
> >>> removed
> >>>> this
> >>>>>>>>>>>>> suppression
> >>>>>>>>>>>>>>>> in "main" code base (not in tests) then it's fine
> >>> and
> >>>> IDE
> >>>>>>>> does not
> >>>>>>>>>>>>>>>> mark the code by inspection. But, if I use
> >>>>>>>>>>>>>>>> 'GridTestUtils#assertThrows' in 'tests' code base,
> >>>> then
> >>>>>> IDE
> >>>>>>>> requires
> >>>>>>>>>>>>>>>> to suppress the inspection, if I have done it then
> >>> TC
> >>>>>> marks
> >>>>>>>> this as
> >>>>>>>>>>>>>>>> "Redundant suppression".
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> What should I do in this case?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Mon, Dec 3, 2018 at 10:26 PM Andrey Mashenkov
> >>>>>>>>>>>>>>>> <an...@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Have someone tried to investigate the issue
> >>> related
> >>>> to
> >>>>>>>> Inspection
> >>>>>>>>>>>>> TC
> >>>>>>>>>>>>>>> task
> >>>>>>>>>>>>>>>>> execution time variation (from 0.5 up to 1,5
> >>> hours)?
> >>>>>>>>>>>>>>>>> Can we enable GC logs for this task or may be even
> >>>> get
> >>>>>>>> CPU, Disk,
> >>>>>>>>>>>>>>> Network
> >>>>>>>>>>>>>>>>> metrics?
> >>>>>>>>>>>>>>>>> Can someone check if there are unnecessary Idea
> >>>> plugins
> >>>>>>>> starts that
> >>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>> safely disabled?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Tue, Nov 27, 2018 at 5:52 PM Dmitriy Pavlov <
> >>>>>>>> dpavlov@apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I'm totally with you in this decision, let's
> >>> move
> >>>> the
> >>>>>>>> file.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> вт, 27 нояб. 2018 г. в 16:24, Maxim Muzafarov <
> >>>>>>>>>>>>> maxmuzaf@gmail.com
> >>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Igniters,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I propose to make inspection configuration
> >>>> default
> >>>>>> on
> >>>>>>>> the
> >>>>>>>>>>>>> project
> >>>>>>>>>>>>>>>>>>> level. I've created a new issue [1] for it. It
> >>>> can
> >>>>>> be
> >>>>>>>> easily
> >>>>>>>>>>>>> done
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>> recommend by IntelliJ documentation [2].
> >>>>>>>>>>>>>>>>>>> Thoughts?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Vyacheslav,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Can you share an example of your warnings?
> >>>>>>>>>>>>>>>>>>> Currently, we have different inspection
> >>>>>>>> configurations:
> >>>>>>>>>>>>>>>>>>> - ignite_inspections.xml - to import
> >>>> inspections as
> >>>>>>>> default and
> >>>>>>>>>>>>>> use
> >>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>> daily.
> >>>>>>>>>>>>>>>>>>> - ignite_inspections_teamcity.xml - config to
> >>>> run it
> >>>>>>>> on TC.
> >>>>>>>>>>>>> Only
> >>>>>>>>>>>>>>>> fixed
> >>>>>>>>>>>>>>>>>>> rules in the project code are enabled. Each of
> >>>> these
> >>>>>>>> rules are
> >>>>>>>>>>>>>>> marked
> >>>>>>>>>>>>>>>>>>> with ERROR level.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>> https://issues.apache.org/jira/browse/IGNITE-10422
> >>>>>>>>>>>>>>>>>>> [2]
> >>>>>>>> https://www.jetbrains.com/help/idea/code-inspection.html
> >>>>>>>>>>>>>>>>>>> On Tue, 20 Nov 2018 at 13:58, Nikolay Izhikov
> >>> <
> >>>>>>>>>>>>>> nizhikov@apache.org
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Hello, Vyacheslav.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Yes, we have.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Maxim Muzafarov, can you fix it, please?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> вт, 20 нояб. 2018 г., 13:10 Vyacheslav
> >>> Daradur
> >>>>>>>>>>>>>>> daradurvs@gmail.com
> >>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Guys, why we have 2 different inspection
> >>>> files
> >>>>>> in
> >>>>>>>> the repo?
> >>>>>>>>>>>>>>>>>>>>> idea\ignite_inspections.xml
> >>>>>>>>>>>>>>>>>>>>> idea\ignite_inspections_teamcity.xml
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> AFAIK TeamCity is able to use the same
> >>>>>> inspection
> >>>>>>>> file with
> >>>>>>>>>>>>>>> IDE.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I've imported
> >>> 'idea\ignite_inspections.xml'
> >>>> in
> >>>>>>>> the IDE, but
> >>>>>>>>>>>>>> now
> >>>>>>>>>>>>>>>> see
> >>>>>>>>>>>>>>>>>>>>> inspection warnings for my PR on TC
> >>> because
> >>>> of
> >>>>>>>> different
> >>>>>>>>>>>>>> rules.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Sun, Nov 11, 2018 at 6:06 PM Maxim
> >>>> Muzafarov
> >>>>>> <
> >>>>>>>>>>>>>>>> maxmuzaf@gmail.com>
> >>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Yakov, Dmitry,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Which example of unsuccessful suite
> >>>> execution
> >>>>>>>> do we need?
> >>>>>>>>>>>>>>>>>>>>>> Does the current fail [1] in the master
> >>>> branch
> >>>>>>>> enough to
> >>>>>>>>>>>>>>>> configure
> >>>>>>>>>>>>>>>>>>>>>> notifications by TC.Bot?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Please consider adding more checks
> >>>>>>>>>>>>>>>>>>>>>>> - line endings. I think we should only
> >>>> have
> >>>>>> \n
> >>>>>>>>>>>>>>>>>>>>>>> - ensure blank line at the end of file
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> It seems to me that `line endings` is
> >>>> easy to
> >>>>>>>> add, but
> >>>>>>>>>>>>> for
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> `blank
> >>>>>>>>>>>>>>>>>>>>>> line at the end` we need as special
> >>>> regexp.
> >>>>>> Can
> >>>>>>>> we focus
> >>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>> built-in
> >>>>>>>>>>>>>>>>>>>>>> IntelliJ inspections at first and fix
> >>>> others
> >>>>>>>> special
> >>>>>>>>>>>>>> further?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> >>>>>>>>>>>>>>>>>>>>>> On Sun, 11 Nov 2018 at 17:55, Maxim
> >>>> Muzafarov
> >>>>>> <
> >>>>>>>>>>>>>>>> maxmuzaf@gmail.com>
> >>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Igniters,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Since the inspection rules are
> >>> included
> >>>> in
> >>>>>>>> RunAll a few
> >>>>>>>>>>>>>>>> members
> >>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> community mentioned a wide distributed
> >>>>>>>> execution time
> >>>>>>>>>>>>> on
> >>>>>>>>>>>>>> TC
> >>>>>>>>>>>>>>>>>> agents:
> >>>>>>>>>>>>>>>>>>>>>>> - 1h:27m:38s publicagent17_9094
> >>>>>>>>>>>>>>>>>>>>>>> - 38m:04s publicagent17_9094
> >>>>>>>>>>>>>>>>>>>>>>> - 33m:29s publicagent17_9094
> >>>>>>>>>>>>>>>>>>>>>>> - 17m:13s publicagent17_9094
> >>>>>>>>>>>>>>>>>>>>>>> It seems that we should configure the
> >>>>>>>> resources
> >>>>>>>>>>>>>>> distribution
> >>>>>>>>>>>>>>>>>>> across TC
> >>>>>>>>>>>>>>>>>>>>>>> containers. Can anyone take a look at
> >>>> it?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I've also prepared the short list of
> >>>> rules
> >>>>>> to
> >>>>>>>> work on:
> >>>>>>>>>>>>>>>>>>>>>>> + Inconsistent line separators (6
> >>>> matches)
> >>>>>>>>>>>>>>>>>>>>>>> + Problematic whitespace (4 matches)
> >>>>>>>>>>>>>>>>>>>>>>> + expression.equals("literal")' rather
> >>>> than
> >>>>>>>>>>>>>>>>>>>>>>> '"literal".equals(expression) (53
> >>>> matches)
> >>>>>>>>>>>>>>>>>>>>>>> + Unnecessary 'null' check before
> >>>>>> 'instanceof'
> >>>>>>>>>>>>> expression
> >>>>>>>>>>>>>>> or
> >>>>>>>>>>>>>>>> call
> >>>>>>>>>>>>>>>>>>> (42
> >>>>>>>>>>>>>>>>>>>>> matches)
> >>>>>>>>>>>>>>>>>>>>>>> + Redundant 'if' statement (69
> >>> matches)
> >>>>>>>>>>>>>>>>>>>>>>> + Redundant interface declaration (28
> >>>>>> matches)
> >>>>>>>>>>>>>>>>>>>>>>> + Double negation (0 matches)
> >>>>>>>>>>>>>>>>>>>>>>> + Unnecessary code block (472 matches)
> >>>>>>>>>>>>>>>>>>>>>>> + Line is longer than allowed by code
> >>>> style
> >>>>>>>> (2614
> >>>>>>>>>>>>>> matches)
> >>>>>>>>>>>>>>>> (Is it
> >>>>>>>>>>>>>>>>>>>>>>> possible to implement?)
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> WDYT?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Fri, 26 Oct 2018 at 23:43, Dmitriy
> >>>>>> Pavlov <
> >>>>>>>>>>>>>>>>>>> dpavlov.spb@gmail.com>
> >>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Hi Maxim,
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> thank you for your efforts to make
> >>>> this
> >>>>>>>> happen. Keep
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> pace!
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Could you please provide an example
> >>>> of how
> >>>>>>>>>>>>> Inspections
> >>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>>>> fail,
> >>>>>>>>>>>>>>>>>>> so
> >>>>>>>>>>>>>>>>>>>>> I or
> >>>>>>>>>>>>>>>>>>>>>>>> another contributor could implement
> >>>>>> support
> >>>>>>>> of these
> >>>>>>>>>>>>>>>> failures
> >>>>>>>>>>>>>>>>>>>>> validation in
> >>>>>>>>>>>>>>>>>>>>>>>> the Tc Bot.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Sincerely,
> >>>>>>>>>>>>>>>>>>>>>>>> Dmitriy Pavlov
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> пт, 26 окт. 2018 г. в 18:27, Yakov
> >>>>>> Zhdanov <
> >>>>>>>>>>>>>>>>>> yzhdanov@apache.org
> >>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Maxim,
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks for response, let's do it
> >>>> the way
> >>>>>>>> you
> >>>>>>>>>>>>>> suggested.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Please consider adding more checks
> >>>>>>>>>>>>>>>>>>>>>>>>> - line endings. I think we should
> >>>> only
> >>>>>>>> have \n
> >>>>>>>>>>>>>>>>>>>>>>>>> - ensure blank line in the end of
> >>>> file
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> All these are code reviews issues
> >>> I
> >>>>>>>> pointed out
> >>>>>>>>>>>>> many
> >>>>>>>>>>>>>>>> times
> >>>>>>>>>>>>>>>>>> when
> >>>>>>>>>>>>>>>>>>>>> reviewing
> >>>>>>>>>>>>>>>>>>>>>>>>> conributions. It would be cool if
> >>> we
> >>>>>> have
> >>>>>>>> TC build
> >>>>>>>>>>>>>>>> failing if
> >>>>>>>>>>>>>>>>>>>>> there is any.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> --Yakov
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>> Best Regards, Vyacheslav D.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>>> Andrey V. Mashenkov
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> Best Regards, Vyacheslav D.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>> Andrey V. Mashenkov
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>> Andrey V. Mashenkov
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Best regards,
> >>>>>>>>>>> Andrey V. Mashenkov
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Best regards,
> >>>>>>>>> Andrey V. Mashenkov
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Best regards,
> >>>>>>> Andrey V. Mashenkov
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Best regards,
> >>>>>> Andrey V. Mashenkov
> >>>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Andrey V. Mashenkov
> >>>
> >
>

Re: Code inspection

[Павлухин Иван <vo...@gmail.com>]

Nikolay,

> This is violation of Ignite code style, so we should fix it for now.
> If we decide to change code style, we can change check.

I wonder if it technically feasible. Do know is it possible to permit
no empty line before a class field?

пн, 3 июн. 2019 г. в 16:56, Nikolay Izhikov <ni...@apache.org>:
>
> Hello, Ivan.
>
> > For me fields without extra empty lines between them look fine.
>
> This is violation of Ignite code style, so we should fix it for now.
> If we decide to change code style, we can change check.
>
> > Can/should we enforce no empty lines there?
>
> You can look into checkstyle documentation for it.
> For now, I don't know about such checks.
>
>
> В Пн, 03/06/2019 в 16:11 +0300, Павлухин Иван пишет:
> > Hi Nikolay,
> >
> > Great, another one nice step to clean code.
> >
> > I scrolled down the commit [1] and have couple of observations:
> > 1. According to our code style agreements each class member should be
> > separated by 1 empty line. As I see there were many places where it
> > was not followed for class fields. E.g. empty lines were added for a
> > code snippet below. For me fields without extra empty lines between
> > them look fine. Of course, it is a question of our agreements. So, we
> > can either permit no empty lines for fields or enforce empty line for
> > each class member.
> > private static class FlaggedCacheOperationCallable implements
> > Callable<GridRestResponse>, Serializable {
> > /** */
> > private static final long serialVersionUID = 0L;
> > /** */
> > private final String cacheName;
> > /** */
> > private final Set<GridClientCacheFlag> cacheFlags;
> >
> > 2. Also I noticed an empty line between a method signature and a first
> > statement in the method in some places, e.g. [2]. Can/should we
> > enforce no empty lines there?
> >
> > And one aside observation (in the same file), it has class fields
> > without a javadoc [3]. Do not our code check jobs enforce javadoc for
> > fields?
> >
> > [1] https://github.com/apache/ignite/commit/d63f4d3569dcb387394d367a7f00aaf35f1b288e
> > [2] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/io/GridReversedLinesFileReader.java#L154
> > [3] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/io/GridReversedLinesFileReader.java#L35
> >
> > вс, 2 июн. 2019 г. в 22:00, Nikolay Izhikov <ni...@apache.org>:
> > >
> > > Hello, Igniters.
> > >
> > > 1. I've added "EmptyLineSeparator" inspection, according to our code style
> > > [1]
> > > 2. I've fixed all current code style violations.
> > >
> > > Please, see my commit [2]
> > >
> > > You may want to merge these changes to your private repos.
> > >
> > > [1]
> > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines
> > > [2]
> > > https://github.com/apache/ignite/commit/d63f4d3569dcb387394d367a7f00aaf35f1b288e
> > >
> > >
> > >
> > >
> > > вт, 23 апр. 2019 г. в 10:45, Vyacheslav Daradur <da...@gmail.com>:
> > >
> > > > Also, I excluded "IntelliJ IDEA Inspections" from RunAll and marked it
> > > > as "~[Excluded]".
> > > >
> > > > On Tue, Apr 23, 2019 at 12:25 AM Vyacheslav Daradur <da...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Maxim, I merged your changes to master.
> > > > >
> > > > > 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.
> > > > >
> > > > > Please check that it works as expected once again and announce new
> > > > > requirements in a separate thread to avoid confusion of community.
> > > > >
> > > > > cc Petr, Pavel (JFYI)
> > > > >
> > > > > [1]
> > > >
> > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=buildTypeBranches
> > > > >
> > > > > On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur <da...@gmail.com>
> > > >
> > > > wrote:
> > > > > >
> > > > > > Maxim,
> > > > > >
> > > > > > I left some comments in Jira, let's resolve them and I'll assist you
> > > > > > with merge and TC configuring.
> > > > > >
> > > > > > On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com>
> > > >
> > > > wrote:
> > > > > > >
> > > > > > > Vyacheslav,
> > > > > > >
> > > > > > > Thank you for your interest in making Ignite coding style better.
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > 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;
> > > > > > >
> > > > > > > On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <
> > > >
> > > > daradurvs@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Maxim,
> > > > > > > >
> > > > > > > > I looked through the PR and it looks good to me in general.
> > > > > > > >
> > > > > > > > The only question how it's planned to maintain check styles in 2
> > > > > > > > different configurations, for IDEA and check style plugin?
> > > > > > > >
> > > > > > > > On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <
> > > >
> > > > maxmuzaf@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Igniters,
> > > > > > > > >
> > > > > > > > > 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).
> > > > > > > > >
> > > > > > > > > JIRA: IGNITE-11277 [1]
> > > > > > > > > PR: [3]
> > > > > > > > > Upsource: [4]
> > > > > > > > >
> > > > > > > > > How can take a look?
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > > > > [2]
> > > >
> > > > http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
> > > > > > > > > [3] https://github.com/apache/ignite/pull/6119
> > > > > > > > > [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
> > > > > > > > >
> > > > > > > > > On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org>
> > > >
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Igniters,
> > > > > > > > > >
> > > > > > > > > > I see that a new TeamCity is released: Version: 2018.2.3.
> > > > > > > > > >
> > > > > > > > > > Probably it could solve recently introduced problem related to:
> > > > > > > > > > Unexpected error during build messages processing in TeamCity;
> > > > > > > > > >
> > > > > > > > > > Peter I., could you please check?
> > > > > > > > > >
> > > > > > > > > > Sincerely,
> > > > > > > > > > Dmitriy Pavlov
> > > > > > > > > >
> > > > > > > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <
> > > >
> > > > vololo100@gmail.com>:
> > > > > > > > > >
> > > > > > > > > > > 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
> > > > > > > > > > > today.
> > > > > > > > > > >
> > > > > > > > > > > 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.
> > > > > > > > > > >
> > > > > > > > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <
> > > >
> > > > vololo100@gmail.com>:
> > > > > > > > > > > >
> > > > > > > > > > > > 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.
> > > > > > > > > > > >
> > > > > > > > > > > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <
> > > >
> > > > nizhikov@apache.org>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > +1 to enable code style checks in compile time.
> > > > > > > > > > > > >
> > > > > > > > > > > > > We can add option to disable maven codestyle profile
> > > >
> > > > with some
> > > > > > > > > > > environment variable.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Anyone who want violate common project rules in their
> > > >
> > > > local branch can
> > > > > > > > > > > set this variable and write some nasty code before push :)
> > > > > > > > > > > > >
> > > > > > > > > > > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <
> > > >
> > > > maxmuzaf@gmail.com>:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 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
> > > > > > > > > > > build stage.
> > > > > > > > > > > > > > - increases a bit the build time procedure
> > > > > > > > > > > > > > - require additional operations to switch it off for
> > > >
> > > > prototyping
> > > > > > > > > > > branches
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > + do not require TC.Bot visa if someone of the
> > > >
> > > > community doesn't use
> > > > > > > > > > > it
> > > > > > > > > > > > > > + 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
> > > > > > > > > > > needs.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 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+Contribute#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, Павлухин Иван <
> > > >
> > > > vololo100@gmail.com>
> > > > > > > > > > > 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:
> > > > > > > > > > > > > > > ====Quoted text====
> > > > > > > > > > > > > > > 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.
> > > > > > > > > > > > > > > 2. Style check takes some time. With simple checks it
> > > >
> > > > is almost
> > > > > > > > > > > > > > > negligible. But it can grow if more checks are
> > > >
> > > > involved.
> > > > > > > > > > > > > > > ====End of quoted text====
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Some clarifications. 1 is about running from IDEA
> > > >
> > > > first. 2 is
> > > > > > > > > > > related
> > > > > > > > > > > > > > > to opinions that we should involve much more checks,
> > > >
> > > > e.g. using
> > > > > > > > > > > > > > > abbreviations.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <
> > > >
> > > > maxmuzaf@gmail.com>:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Ivan,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Let's take a look at all the options we have
> > > >
> > > > (ordered by the
> > > > > > > > > > > frequency 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
> > > > > > > > > > > checkstyle plugin is used in the <build> 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.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Back to our use cases:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 1. For checking the ready to merge branches we will
> > > >
> > > > fail the
> > > > > > > > > > > ~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.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 2. For the prototyping branches, you can turn off
> > > >
> > > > checkstyle in
> > > > > > > > > > > your 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
> > > > > > > > > > > checkstyle enabled profile. The common build action as `mvn
> > > >
> > > > clean install
> > > > > > > > > > > -DskipTests` will activate the profile.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 4. The checkstyle profile can be disabled
> > > >
> > > > explicitly on TC by
> > > > > > > > > > > specifying -P !checkstyle option. A don't see any use cases
> > > >
> > > > of it, but it's
> > > > > > > > > > > completely doable.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Please, correct me if I've missed something.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I propose to merge PR [1] as it is, with the
> > > >
> > > > configured set of
> > > > > > > > > > > rules.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > [1] https://github.com/apache/ignite/pull/6119
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <
> > > >
> > > > vololo100@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Maxim,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I like an idea of being IDE agnostic. I am ok with
> > > >
> > > > currently
> > > > > > > > > > > enabled
> > > > > > > > > > > > > > > > > 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
> > > > > > > > > > > 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.
> > > > > > > > > > > > > > > > > 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"
> > > > > > > > > > > which I
> > > > > > > > > > > > > > > > > think is quite useful.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <
> > > >
> > > > maxmuzaf@gmail.com
> > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Ivan,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I like that Jetbrains inspections are integrated
> > > >
> > > > with IDE and
> > > > > > > > > > > TC 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
> > > > > > > > > > > with code
> > > > > > > > > > > > > > > > > > style checking. I've checked popular java
> > > >
> > > > projects: hadoop,
> > > > > > > > > > > kafka,
> > > > > > > > > > > > > > > > > > spark, hive, netty. All of them are using
> > > > > > > > > > >
> > > > > > > > > > > maven-checkstyle-plugin in
> > > > > > > > > > > > > > > > > > their <build> 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
> > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > SizeReplaceableByIsEmpty (all code style checks
> > > >
> > > > [5]). Propose
> > > > > > > > > > > to 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-1018
> > > > > > > > > > > > > > > > > > [4]
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > > > > > > > > > > > > > > > > > [5]
> > > >
> > > > http://checkstyle.sourceforge.net/checks.html
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> > > > > > > > > > >
> > > > > > > > > > > vololo100@gmail.com> 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
> > > > > > > > > > > checkstyle
> > > > > > > > > > > > > > > > > > > plugin? Is it integrated into IDEA out of box?
> > > >
> > > > As I got it
> > > > > > > > > > > additional
> > > > > > > > > > > > > > > > > > > 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
> > > > > > > > > > > visa. Visa
> > > > > > > > > > > > > > > > > > > includes result from running inspections job.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> > > > > > > > > > >
> > > > > > > > > > > nizhikov@apache.org>:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 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.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> > > > > > > > > > >
> > > > > > > > > > > vololo100@gmail.com>:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Nikolay,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Should the community spend TC resources
> > > >
> > > > for  prototype?
> > > > > > > > > > > > > > > > > > > > > Why not? I think it is not bad idea to run
> > > >
> > > > all tests
> > > > > > > > > > > against 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
> > > > > > > > > > > with other
> > > > > > > > > > > > > > > > > > > > > Igniters. I think it is the cheapest way
> > > >
> > > > to check the
> > > > > > > > > > > idea because the
> > > > > > > > > > > > > > > > > > > > > check is fully automated. Requiring a
> > > >
> > > > human feedback is
> > > > > > > > > > > much 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
> > > > > > > > > > > skipping tests
> > > > > > > > > > > > > > > > > > > > > execution if inspections detect a problem?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay
> > > >
> > > > Izhikov <
> > > > > > > > > > > nizhikov@apache.org>:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 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
> > > > > > > > > > > prototype.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 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?
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин
> > > >
> > > > Иван <
> > > > > > > > > > > vololo100@gmail.com>:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 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
> > > > > > > > > > > outline 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
> > > > > > > > > > > that message).
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > We have a document defining code style
> > > >
> > > > which every
> > > > > > > > > > > contributor should
> > > > > > > > > > > > > > > > > > > > > > > follow [1]. And many points can be
> > > >
> > > > checked
> > > > > > > > > > > automatically. Personally,
> > > > > > > > > > > > > > > > > > > > > > > I do not see much need in writing good
> > > >
> > > > javadocs for
> > > > > > > > > > > prototype. Why
> > > > > > > > > > > > > > > > > > > > > > > should I stub it to be able run any
> > > >
> > > > build on TC?
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Also, we a have a review process which
> > > >
> > > > should be
> > > > > > > > > > > applied to every
> > > > > > > > > > > > > > > > > > > > > > > patch. Partially it is described in
> > > >
> > > > [2]. And due to
> > > > > > > > > > > this process every
> > > > > > > > > > > > > > > > > > > > > > > patch should not introduce new
> > > >
> > > > failures on TC. So,
> > > > > > > > > > > the patch should
> > > > > > > > > > > > > > > > > > > > > > > not be merged if inspections failed.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > P.S. Something more about prototypes
> > > >
> > > > and production
> > > > > > > > > > > code. There is a
> > > > > > > > > > > > > > > > > > > > > > > common bad practice in software
> > > >
> > > > engineering. It is
> > > > > > > > > > > turning prototypes
> > > > > > > > > > > > > > > > > > > > > > > into production code. Often it is much
> > > >
> > > > faster to
> > > > > > > > > > > create a prototype by
> > > > > > > > > > > > > > > > > > > > > > > price of violating some rules of
> > > >
> > > > writing "clean
> > > > > > > > > > > code". And often
> > > > > > > > > > > > > > > > > > > > > > > prototype after successful piloting is
> > > >
> > > > turned into
> > > > > > > > > > > production code.
> > > > > > > > > > > > > > > > > > > > > > > And it is very easy in practice to
> > > >
> > > > keep some pieces
> > > > > > > > > > > of 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"
> > > > > > > > > > > from the beginning.
> > > > > > > > > > > > > > > > > > > > > > > So, only ideas are taken from the
> > > >
> > > > prototype and a
> > > > > > > > > > > code is fully
> > > > > > > > > > > > > > > > > > > > > > > rewritten.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > [1]
> > > >
> > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > > > > > > > > > > > > > > > > > > > > [2]
> > > >
> > > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim
> > > >
> > > > Muzafarov <
> > > > > > > > > > > maxmuzaf@gmail.com>:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Ivan,
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > As the first implementation of this
> > > >
> > > > addition, I'd
> > > > > > > > > > > prefer to make it
> > > > > > > > > > > > > > > > > > > > > > > > working like _Licenses Headers_
> > > >
> > > > suite check. It
> > > > > > > > > > > will fail when some
> > > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > > > the code style checks violated.
> > > >
> > > > Moreover, these
> > > > > > > > > > > licenses header
> > > > > > > > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > > > > > > > > > > can be included in the checkstyle
> > > >
> > > > plugin
> > > > > > > > > > > configuration.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > In general, I'd prefer to have a
> > > >
> > > > compilation fail
> > > > > > > > > > > error with code
> > > > > > > > > > > > > > > > > > > > > > > > style checks and after we will get a
> > > >
> > > > stable
> > > > > > > > > > > checkstyle suite I
> > > > > > > > > > > > > > > > > > > > > propose
> > > > > > > > > > > > > > > > > > > > > > > > to change it in a "compilation
> > > >
> > > > error" way. If we
> > > > > > > > > > > are talking about
> > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > coding style convenient for most of
> > > >
> > > > the community
> > > > > > > > > > > members I see no
> > > > > > > > > > > > > > > > > > > > > > > > difference with coding sketches or
> > > > > > > > > > >
> > > > > > > > > > > production-ready branches equally.
> > > > > > > > > > > > > > > > > > > > > > > > Indeed, no one will be against
> > > >
> > > > unused imports [or
> > > > > > > > > > > spaces 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() == 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 <
> > > > > > > > > > > nizhikov@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Actually, I dont see anything
> > > >
> > > > wrong with failing
> > > > > > > > > > > *compilation*
> > > > > > > > > > > > > > > > > > > > > task.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I think one should use project
> > > >
> > > > code style for
> > > > > > > > > > > everyday 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?
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr
> > > >
> > > > Ivanov
> > > > > > > > > > > mr.weider@gmail.com:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > I guess that was about failing
> > > >
> > > > build
> > > > > > > > > > > configuration with
> > > > > > > > > > > > > > > > > > > > > Checkstype,
> > > > > > > > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > > > > > > > > compilation build itself.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > On 12 Feb 2019, at 18:03,
> > > >
> > > > Павлухин Иван <
> > > > > > > > > > > vololo100@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Folks,
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Are you going to fail job
> > > >
> > > > compiling Ignite
> > > > > > > > > > > sources [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
> > > > > > > > > > > convenient to skip some
> > > > > > > > > > > > > > > > > > > > > style
> > > > > > > > > > > > > > > > > > > > > > > > > > > requirements for such sketches
> > > >
> > > > (e.g. well
> > > > > > > > > > > formed javadocs).
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > [1]
> > > >
> > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38,
> > > >
> > > > Nikolay
> > > > > > > > > > > Izhikov <
> > > > > > > > > > > > > > > > > > > > > nizhikov@apache.org
> > > > > > > > > > > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Petr, we should have 1
> > > >
> > > > configuration for
> > > > > > > > > > > project, may be 1
> > > > > > > > > > > > > > > > > > > > > > > configuration
> > > > > > > > > > > > > > > > > > > > > > > > > > > > per programming language.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > пн, 11 февр. 2019 г., 11:33
> > > >
> > > > Petr Ivanov
> > > > > > > > > > > mr.weider@gmail.com:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > I was asking about how many
> > > >
> > > > build
> > > > > > > > > > > configuration is intended?
> > > > > > > > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > and multiple per module?
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > With IDEA inspections it was
> > > >
> > > > going to be
> > > > > > > > > > > build 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
> > > > > > > > > > > build task? And each
> > > > > > > > > > > > > > > > > > > > > > > module
> > > > > > > > > > > > > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > when it required? If yes,
> > > >
> > > > then I propose
> > > > > > > > > > > to create a task
> > > > > > > > > > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > > > > > > > > > > > "Licence
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > check" which will be run
> > > >
> > > > for every patch.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My point is that violation
> > > >
> > > > of codestyle
> > > > > > > > > > > should be treated as
> > > > > > > > > > > > > > > > > > > > > > > hard as
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > compile error.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > пн, 11 февр. 2019 г., 11:16
> > > >
> > > > Petr Ivanov
> > > > > > > > > > > mr.weider@gmail.com
> > > > > > > > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is build configuration
> > > >
> > > > Inspections
> > > > > > > > > > > [Core] meant to
> > > > > > > > > > > > > > > > > > > > > transform
> > > > > > > > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > > > > > > > > > single
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > all-modules check build
> > > >
> > > > configuration
> > > > > > > > > > > (without module
> > > > > > > > > > > > > > > > > > > > > > > subdivision)?
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11 Feb 2019, at 11:02,
> > > >
> > > > Nikolay
> > > > > > > > > > > Izhikov <
> > > > > > > > > > > > > > > > > > > > > > > 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/1065-checkstyle-idea
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I propose do the
> > > >
> > > > following:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. Migrate current checks
> > > >
> > > > to checkstyle.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2. Apply checks to all
> > > >
> > > > Ignite modules.
> > > > > > > > > > > Currently, 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
> > > > > > > > > > > Apache Ignite"
> > > > > > > > > > > > > > > > > > > > > suite.
> > > > > > > > > > > > > > > > > > > > > > > Ignite
> > > > > > > > > > > > > > > > > > > > > > > > > > has
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > fail to build if patch
> > > >
> > > > violates
> > > > > > > > > > > codestyle.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > вс, 10 февр. 2019 г. в
> > > >
> > > > 07:54, Павлухин
> > > > > > > > > > > Иван <
> > > > > > > > > > > > > > > > > > > > > > > vololo100@gmail.com>:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also think that some
> > > >
> > > > warning from
> > > > > > > > > > > IDEA that some code
> > > > > > > > > > > > > > > > > > > > > > > style rule
> > > > > > > > > > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > violated is a must-have.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > вс, 10 февр. 2019 г. в
> > > >
> > > > 01:58,
> > > > > > > > > > > oignatenko <
> > > > > > > > > > > > > > > > > > > > > > > oignatenko@gridgain.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Maxim,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe that whatever
> > > >
> > > > style checks
> > > > > > > > > > > we establish at
> > > > > > > > > > > > > > > > > > > > > > > Teamcity, we
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > better
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > take care of making it
> > > >
> > > > easy for
> > > > > > > > > > > developers to find and
> > > > > > > > > > > > > > > > > > > > > fix
> > > > > > > > > > > > > > > > > > > > > > > > > > violations
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > their typical dev
> > > >
> > > > environment (for
> > > > > > > > > > > Ignite this means, in
> > > > > > > > > > > > > > > > > > > > > > > IDEA). I
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > think
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > is important that
> > > >
> > > > developers can
> > > > > > > > > > > maintain 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
> > > > > > > > > > > just 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
> > > > > > > > > > > checkstyle - I
> > > > > > > > > > > > > > > > > > > > > recommend
> > > > > > > > > > > > > > > > > > > > > > > keeping
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > config file somewhere
> > > >
> > > > in the project
> > > > > > > > > > > under version
> > > > > > > > > > > > > > > > > > > > > control.
> > > > > > > > > > > > > > > > > > > > > > > I
> > > > > > > > > > > > > > > > > > > > > > > > > > used to
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > maintain such a shared
> > > >
> > > > style config
> > > > > > > > > > > at one of past jobs
> > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > experimenting it turned
> > > >
> > > > out most
> > > > > > > > > > > convenient to have it
> > > > > > > > > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > > > > > > > > way -
> > > > > > > > > > > > > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > developers could easily
> > > >
> > > > assess and
> > > > > > > > > > > discuss style
> > > > > > > > > > > > > > > > > > > > > settings
> > > > > > > > > > > > > > > > > > > > > > > and keep
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > track
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > changes in these. (note
> > > >
> > > > how Kafka
> > > > > > > > > > > folks 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
> > > > > > > > > > > community members.
> > > > > > > > > > > > > > > > > > > > > > > Moreover, this
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > suite is no longer
> > > >
> > > > checks rules we
> > > > > > > > > > > previously
> > > > > > > > > > > > > > > > > > > > > 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
> > > > > > > > > > > consider the Apache Kafka
> > > > > > > > > > > > > > > > > > > > > > > code
> > > > > > > > > > > > > > > > > > > > > > > > > > style
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > [5]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > way and configure for
> > > >
> > > > the Ignite
> > > > > > > > > > > project a
> > > > > > > > > > > > > > > > > > > > > > > > > > maven-checkstyle-plugin
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > with its own maven
> > > >
> > > > profile and run
> > > > > > > > > > > it simultaneously
> > > > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > > > other
> > > > > > > > > > > > > > > > > > > > > > > > > > TC.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > We
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > can also enable the
> > > >
> > > > previously
> > > > > > > > > > > configured inspection
> > > > > > > > > > > > > > > > > > > > > > > rules, so no
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > coding style
> > > >
> > > > violations will be
> > > > > > > > > > > missed.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I see some advantages
> > > >
> > > > of using a
> > > > > > > > > > > maven plugin:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - an IDE agnostic way
> > > >
> > > > for code checks
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - can be used with
> > > >
> > > > different CI and
> > > > > > > > > > > build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [2]
> > > > > > > > > > >
> > > > > > > > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [3]
> > > >
> > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [4]
> > > > > > > > > > >
> > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [5]
> > > >
> > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 21 Dec 2018 at
> > > >
> > > > 16:03, Petr
> > > > > > > > > > > Ivanov &lt;
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > mr.weider@
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > &gt; wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It seems there is bug
> > > >
> > > > in latest
> > > > > > > > > > > 2018.2 TeamCity
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bug is filed [1]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > >
> > > > > > > > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 19 Dec 2018, at
> > > >
> > > > 11:31, Petr
> > > > > > > > > > > Ivanov &lt;
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > mr.weider@
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > &gt; wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Investigating
> > > >
> > > > problem, stand by.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 18 Dec 2018, at
> > > >
> > > > 19:41, Dmitriy
> > > > > > > > > > > Pavlov &lt;
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > dpavlov@
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > &gt; 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
> > > > > > > > > > > next 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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Best regards,
> > > > > > > > > > > Ivan Pavlukhin
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> >
> >
> >



-- 
Best regards,
Ivan Pavlukhin

Re: Code inspection

[Nikolay Izhikov <ni...@apache.org>]

Hello, Ivan.

> For me fields without extra empty lines between them look fine.

This is violation of Ignite code style, so we should fix it for now.
If we decide to change code style, we can change check.

> Can/should we enforce no empty lines there?

You can look into checkstyle documentation for it.
For now, I don't know about such checks.


В Пн, 03/06/2019 в 16:11 +0300, Павлухин Иван пишет:
> Hi Nikolay,
> 
> Great, another one nice step to clean code.
> 
> I scrolled down the commit [1] and have couple of observations:
> 1. According to our code style agreements each class member should be
> separated by 1 empty line. As I see there were many places where it
> was not followed for class fields. E.g. empty lines were added for a
> code snippet below. For me fields without extra empty lines between
> them look fine. Of course, it is a question of our agreements. So, we
> can either permit no empty lines for fields or enforce empty line for
> each class member.
> private static class FlaggedCacheOperationCallable implements
> Callable<GridRestResponse>, Serializable {
> /** */
> private static final long serialVersionUID = 0L;
> /** */
> private final String cacheName;
> /** */
> private final Set<GridClientCacheFlag> cacheFlags;
> 
> 2. Also I noticed an empty line between a method signature and a first
> statement in the method in some places, e.g. [2]. Can/should we
> enforce no empty lines there?
> 
> And one aside observation (in the same file), it has class fields
> without a javadoc [3]. Do not our code check jobs enforce javadoc for
> fields?
> 
> [1] https://github.com/apache/ignite/commit/d63f4d3569dcb387394d367a7f00aaf35f1b288e
> [2] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/io/GridReversedLinesFileReader.java#L154
> [3] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/io/GridReversedLinesFileReader.java#L35
> 
> вс, 2 июн. 2019 г. в 22:00, Nikolay Izhikov <ni...@apache.org>:
> > 
> > Hello, Igniters.
> > 
> > 1. I've added "EmptyLineSeparator" inspection, according to our code style
> > [1]
> > 2. I've fixed all current code style violations.
> > 
> > Please, see my commit [2]
> > 
> > You may want to merge these changes to your private repos.
> > 
> > [1]
> > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines
> > [2]
> > https://github.com/apache/ignite/commit/d63f4d3569dcb387394d367a7f00aaf35f1b288e
> > 
> > 
> > 
> > 
> > вт, 23 апр. 2019 г. в 10:45, Vyacheslav Daradur <da...@gmail.com>:
> > 
> > > Also, I excluded "IntelliJ IDEA Inspections" from RunAll and marked it
> > > as "~[Excluded]".
> > > 
> > > On Tue, Apr 23, 2019 at 12:25 AM Vyacheslav Daradur <da...@gmail.com>
> > > wrote:
> > > > 
> > > > Maxim, I merged your changes to master.
> > > > 
> > > > 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.
> > > > 
> > > > Please check that it works as expected once again and announce new
> > > > requirements in a separate thread to avoid confusion of community.
> > > > 
> > > > cc Petr, Pavel (JFYI)
> > > > 
> > > > [1]
> > > 
> > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=buildTypeBranches
> > > > 
> > > > On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur <da...@gmail.com>
> > > 
> > > wrote:
> > > > > 
> > > > > Maxim,
> > > > > 
> > > > > I left some comments in Jira, let's resolve them and I'll assist you
> > > > > with merge and TC configuring.
> > > > > 
> > > > > On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com>
> > > 
> > > wrote:
> > > > > > 
> > > > > > Vyacheslav,
> > > > > > 
> > > > > > Thank you for your interest in making Ignite coding style better.
> > > > > > 
> > > > > > 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.
> > > > > > 
> > > > > > 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.
> > > > > > 
> > > > > > 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;
> > > > > > 
> > > > > > On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <
> > > 
> > > daradurvs@gmail.com> wrote:
> > > > > > > 
> > > > > > > Maxim,
> > > > > > > 
> > > > > > > I looked through the PR and it looks good to me in general.
> > > > > > > 
> > > > > > > The only question how it's planned to maintain check styles in 2
> > > > > > > different configurations, for IDEA and check style plugin?
> > > > > > > 
> > > > > > > On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <
> > > 
> > > maxmuzaf@gmail.com> wrote:
> > > > > > > > 
> > > > > > > > Igniters,
> > > > > > > > 
> > > > > > > > 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).
> > > > > > > > 
> > > > > > > > JIRA: IGNITE-11277 [1]
> > > > > > > > PR: [3]
> > > > > > > > Upsource: [4]
> > > > > > > > 
> > > > > > > > How can take a look?
> > > > > > > > 
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > > > [2]
> > > 
> > > http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
> > > > > > > > [3] https://github.com/apache/ignite/pull/6119
> > > > > > > > [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
> > > > > > > > 
> > > > > > > > On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org>
> > > 
> > > wrote:
> > > > > > > > > 
> > > > > > > > > Hi Igniters,
> > > > > > > > > 
> > > > > > > > > I see that a new TeamCity is released: Version: 2018.2.3.
> > > > > > > > > 
> > > > > > > > > Probably it could solve recently introduced problem related to:
> > > > > > > > > Unexpected error during build messages processing in TeamCity;
> > > > > > > > > 
> > > > > > > > > Peter I., could you please check?
> > > > > > > > > 
> > > > > > > > > Sincerely,
> > > > > > > > > Dmitriy Pavlov
> > > > > > > > > 
> > > > > > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <
> > > 
> > > vololo100@gmail.com>:
> > > > > > > > > 
> > > > > > > > > > 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
> > > > > > > > > > today.
> > > > > > > > > > 
> > > > > > > > > > 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.
> > > > > > > > > > 
> > > > > > > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <
> > > 
> > > vololo100@gmail.com>:
> > > > > > > > > > > 
> > > > > > > > > > > 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.
> > > > > > > > > > > 
> > > > > > > > > > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <
> > > 
> > > nizhikov@apache.org>:
> > > > > > > > > > > > 
> > > > > > > > > > > > +1 to enable code style checks in compile time.
> > > > > > > > > > > > 
> > > > > > > > > > > > We can add option to disable maven codestyle profile
> > > 
> > > with some
> > > > > > > > > > environment variable.
> > > > > > > > > > > > 
> > > > > > > > > > > > Anyone who want violate common project rules in their
> > > 
> > > local branch can
> > > > > > > > > > set this variable and write some nasty code before push :)
> > > > > > > > > > > > 
> > > > > > > > > > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <
> > > 
> > > maxmuzaf@gmail.com>:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 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
> > > > > > > > > > build stage.
> > > > > > > > > > > > > - increases a bit the build time procedure
> > > > > > > > > > > > > - require additional operations to switch it off for
> > > 
> > > prototyping
> > > > > > > > > > branches
> > > > > > > > > > > > > 
> > > > > > > > > > > > > + do not require TC.Bot visa if someone of the
> > > 
> > > community doesn't use
> > > > > > > > > > it
> > > > > > > > > > > > > + 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
> > > > > > > > > > needs.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 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+Contribute#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, Павлухин Иван <
> > > 
> > > vololo100@gmail.com>
> > > > > > > > > > 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:
> > > > > > > > > > > > > > ====Quoted text====
> > > > > > > > > > > > > > 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.
> > > > > > > > > > > > > > 2. Style check takes some time. With simple checks it
> > > 
> > > is almost
> > > > > > > > > > > > > > negligible. But it can grow if more checks are
> > > 
> > > involved.
> > > > > > > > > > > > > > ====End of quoted text====
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Some clarifications. 1 is about running from IDEA
> > > 
> > > first. 2 is
> > > > > > > > > > related
> > > > > > > > > > > > > > to opinions that we should involve much more checks,
> > > 
> > > e.g. using
> > > > > > > > > > > > > > abbreviations.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <
> > > 
> > > maxmuzaf@gmail.com>:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Ivan,
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Let's take a look at all the options we have
> > > 
> > > (ordered by the
> > > > > > > > > > frequency 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
> > > > > > > > > > checkstyle plugin is used in the <build> 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.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Back to our use cases:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 1. For checking the ready to merge branches we will
> > > 
> > > fail the
> > > > > > > > > > ~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.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 2. For the prototyping branches, you can turn off
> > > 
> > > checkstyle in
> > > > > > > > > > your 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
> > > > > > > > > > checkstyle enabled profile. The common build action as `mvn
> > > 
> > > clean install
> > > > > > > > > > -DskipTests` will activate the profile.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 4. The checkstyle profile can be disabled
> > > 
> > > explicitly on TC by
> > > > > > > > > > specifying -P !checkstyle option. A don't see any use cases
> > > 
> > > of it, but it's
> > > > > > > > > > completely doable.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Please, correct me if I've missed something.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I propose to merge PR [1] as it is, with the
> > > 
> > > configured set of
> > > > > > > > > > rules.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > [1] https://github.com/apache/ignite/pull/6119
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <
> > > 
> > > vololo100@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Maxim,
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I like an idea of being IDE agnostic. I am ok with
> > > 
> > > currently
> > > > > > > > > > enabled
> > > > > > > > > > > > > > > > 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
> > > > > > > > > > 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.
> > > > > > > > > > > > > > > > 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"
> > > > > > > > > > which I
> > > > > > > > > > > > > > > > think is quite useful.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <
> > > 
> > > maxmuzaf@gmail.com
> > > > > > > > > > > :
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Ivan,
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > I like that Jetbrains inspections are integrated
> > > 
> > > with IDE and
> > > > > > > > > > TC 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
> > > > > > > > > > with code
> > > > > > > > > > > > > > > > > style checking. I've checked popular java
> > > 
> > > projects: hadoop,
> > > > > > > > > > kafka,
> > > > > > > > > > > > > > > > > spark, hive, netty. All of them are using
> > > > > > > > > > 
> > > > > > > > > > maven-checkstyle-plugin in
> > > > > > > > > > > > > > > > > their <build> 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
> > > > > > > > > > and
> > > > > > > > > > > > > > > > > SizeReplaceableByIsEmpty (all code style checks
> > > 
> > > [5]). Propose
> > > > > > > > > > to 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-1018
> > > > > > > > > > > > > > > > > [4]
> > > 
> > > https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > > > > > > > > > > > > > > > > [5]
> > > 
> > > http://checkstyle.sourceforge.net/checks.html
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> > > > > > > > > > 
> > > > > > > > > > vololo100@gmail.com> 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
> > > > > > > > > > checkstyle
> > > > > > > > > > > > > > > > > > plugin? Is it integrated into IDEA out of box?
> > > 
> > > As I got it
> > > > > > > > > > additional
> > > > > > > > > > > > > > > > > > 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
> > > > > > > > > > visa. Visa
> > > > > > > > > > > > > > > > > > includes result from running inspections job.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> > > > > > > > > > 
> > > > > > > > > > nizhikov@apache.org>:
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > 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.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> > > > > > > > > > 
> > > > > > > > > > vololo100@gmail.com>:
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Nikolay,
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Should the community spend TC resources
> > > 
> > > for  prototype?
> > > > > > > > > > > > > > > > > > > > Why not? I think it is not bad idea to run
> > > 
> > > all tests
> > > > > > > > > > against 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
> > > > > > > > > > with other
> > > > > > > > > > > > > > > > > > > > Igniters. I think it is the cheapest way
> > > 
> > > to check the
> > > > > > > > > > idea because the
> > > > > > > > > > > > > > > > > > > > check is fully automated. Requiring a
> > > 
> > > human feedback is
> > > > > > > > > > much 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
> > > > > > > > > > skipping tests
> > > > > > > > > > > > > > > > > > > > execution if inspections detect a problem?
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay
> > > 
> > > Izhikov <
> > > > > > > > > > nizhikov@apache.org>:
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > 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
> > > > > > > > > > prototype.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > 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?
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин
> > > 
> > > Иван <
> > > > > > > > > > vololo100@gmail.com>:
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > 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
> > > > > > > > > > outline 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
> > > > > > > > > > that message).
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > We have a document defining code style
> > > 
> > > which every
> > > > > > > > > > contributor should
> > > > > > > > > > > > > > > > > > > > > > follow [1]. And many points can be
> > > 
> > > checked
> > > > > > > > > > automatically. Personally,
> > > > > > > > > > > > > > > > > > > > > > I do not see much need in writing good
> > > 
> > > javadocs for
> > > > > > > > > > prototype. Why
> > > > > > > > > > > > > > > > > > > > > > should I stub it to be able run any
> > > 
> > > build on TC?
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > Also, we a have a review process which
> > > 
> > > should be
> > > > > > > > > > applied to every
> > > > > > > > > > > > > > > > > > > > > > patch. Partially it is described in
> > > 
> > > [2]. And due to
> > > > > > > > > > this process every
> > > > > > > > > > > > > > > > > > > > > > patch should not introduce new
> > > 
> > > failures on TC. So,
> > > > > > > > > > the patch should
> > > > > > > > > > > > > > > > > > > > > > not be merged if inspections failed.
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > P.S. Something more about prototypes
> > > 
> > > and production
> > > > > > > > > > code. There is a
> > > > > > > > > > > > > > > > > > > > > > common bad practice in software
> > > 
> > > engineering. It is
> > > > > > > > > > turning prototypes
> > > > > > > > > > > > > > > > > > > > > > into production code. Often it is much
> > > 
> > > faster to
> > > > > > > > > > create a prototype by
> > > > > > > > > > > > > > > > > > > > > > price of violating some rules of
> > > 
> > > writing "clean
> > > > > > > > > > code". And often
> > > > > > > > > > > > > > > > > > > > > > prototype after successful piloting is
> > > 
> > > turned into
> > > > > > > > > > production code.
> > > > > > > > > > > > > > > > > > > > > > And it is very easy in practice to
> > > 
> > > keep some pieces
> > > > > > > > > > of 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"
> > > > > > > > > > from the beginning.
> > > > > > > > > > > > > > > > > > > > > > So, only ideas are taken from the
> > > 
> > > prototype and a
> > > > > > > > > > code is fully
> > > > > > > > > > > > > > > > > > > > > > rewritten.
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > [1]
> > > 
> > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > > > > > > > > > > > > > > > > > > > [2]
> > > 
> > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim
> > > 
> > > Muzafarov <
> > > > > > > > > > maxmuzaf@gmail.com>:
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > Ivan,
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > As the first implementation of this
> > > 
> > > addition, I'd
> > > > > > > > > > prefer to make it
> > > > > > > > > > > > > > > > > > > > > > > working like _Licenses Headers_
> > > 
> > > suite check. It
> > > > > > > > > > will fail when some
> > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > > the code style checks violated.
> > > 
> > > Moreover, these
> > > > > > > > > > licenses header
> > > > > > > > > > > > > > > > > > > > checks
> > > > > > > > > > > > > > > > > > > > > > > can be included in the checkstyle
> > > 
> > > plugin
> > > > > > > > > > configuration.
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > In general, I'd prefer to have a
> > > 
> > > compilation fail
> > > > > > > > > > error with code
> > > > > > > > > > > > > > > > > > > > > > > style checks and after we will get a
> > > 
> > > stable
> > > > > > > > > > checkstyle suite I
> > > > > > > > > > > > > > > > > > > > propose
> > > > > > > > > > > > > > > > > > > > > > > to change it in a "compilation
> > > 
> > > error" way. If we
> > > > > > > > > > are talking about
> > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > coding style convenient for most of
> > > 
> > > the community
> > > > > > > > > > members I see no
> > > > > > > > > > > > > > > > > > > > > > > difference with coding sketches or
> > > > > > > > > > 
> > > > > > > > > > production-ready branches equally.
> > > > > > > > > > > > > > > > > > > > > > > Indeed, no one will be against
> > > 
> > > unused imports [or
> > > > > > > > > > spaces 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() == 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 <
> > > > > > > > > > nizhikov@apache.org>
> > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > Actually, I dont see anything
> > > 
> > > wrong with failing
> > > > > > > > > > *compilation*
> > > > > > > > > > > > > > > > > > > > task.
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > I think one should use project
> > > 
> > > code style for
> > > > > > > > > > everyday 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?
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr
> > > 
> > > Ivanov
> > > > > > > > > > mr.weider@gmail.com:
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > I guess that was about failing
> > > 
> > > build
> > > > > > > > > > configuration with
> > > > > > > > > > > > > > > > > > > > Checkstype,
> > > > > > > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > > > > > > > compilation build itself.
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > On 12 Feb 2019, at 18:03,
> > > 
> > > Павлухин Иван <
> > > > > > > > > > vololo100@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > Folks,
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > Are you going to fail job
> > > 
> > > compiling Ignite
> > > > > > > > > > sources [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
> > > > > > > > > > convenient to skip some
> > > > > > > > > > > > > > > > > > > > style
> > > > > > > > > > > > > > > > > > > > > > > > > > requirements for such sketches
> > > 
> > > (e.g. well
> > > > > > > > > > formed javadocs).
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > [1]
> > > 
> > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38,
> > > 
> > > Nikolay
> > > > > > > > > > Izhikov <
> > > > > > > > > > > > > > > > > > > > nizhikov@apache.org
> > > > > > > > > > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > Petr, we should have 1
> > > 
> > > configuration for
> > > > > > > > > > project, may be 1
> > > > > > > > > > > > > > > > > > > > > > configuration
> > > > > > > > > > > > > > > > > > > > > > > > > > > per programming language.
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > пн, 11 февр. 2019 г., 11:33
> > > 
> > > Petr Ivanov
> > > > > > > > > > mr.weider@gmail.com:
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > I was asking about how many
> > > 
> > > build
> > > > > > > > > > configuration is intended?
> > > > > > > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > > > > > > > > > > and multiple per module?
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > With IDEA inspections it was
> > > 
> > > going to be
> > > > > > > > > > build 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
> > > > > > > > > > build task? And each
> > > > > > > > > > > > > > > > > > > > > > module
> > > > > > > > > > > > > > > > > > > > > > > > > builds
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > when it required? If yes,
> > > 
> > > then I propose
> > > > > > > > > > to create a task
> > > > > > > > > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > > > > > > > > > > "Licence
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > check" which will be run
> > > 
> > > for every patch.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > My point is that violation
> > > 
> > > of codestyle
> > > > > > > > > > should be treated as
> > > > > > > > > > > > > > > > > > > > > > hard as
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > compile error.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > пн, 11 февр. 2019 г., 11:16
> > > 
> > > Petr Ivanov
> > > > > > > > > > mr.weider@gmail.com
> > > > > > > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is build configuration
> > > 
> > > Inspections
> > > > > > > > > > [Core] meant to
> > > > > > > > > > > > > > > > > > > > transform
> > > > > > > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > > > > > > > > single
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > all-modules check build
> > > 
> > > configuration
> > > > > > > > > > (without module
> > > > > > > > > > > > > > > > > > > > > > subdivision)?
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11 Feb 2019, at 11:02,
> > > 
> > > Nikolay
> > > > > > > > > > Izhikov <
> > > > > > > > > > > > > > > > > > > > > > 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/1065-checkstyle-idea
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I propose do the
> > > 
> > > following:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. Migrate current checks
> > > 
> > > to checkstyle.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2. Apply checks to all
> > > 
> > > Ignite modules.
> > > > > > > > > > Currently, 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
> > > > > > > > > > Apache Ignite"
> > > > > > > > > > > > > > > > > > > > suite.
> > > > > > > > > > > > > > > > > > > > > > Ignite
> > > > > > > > > > > > > > > > > > > > > > > > > has
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > fail to build if patch
> > > 
> > > violates
> > > > > > > > > > codestyle.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > вс, 10 февр. 2019 г. в
> > > 
> > > 07:54, Павлухин
> > > > > > > > > > Иван <
> > > > > > > > > > > > > > > > > > > > > > vololo100@gmail.com>:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also think that some
> > > 
> > > warning from
> > > > > > > > > > IDEA that some code
> > > > > > > > > > > > > > > > > > > > > > style rule
> > > > > > > > > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > violated is a must-have.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > вс, 10 февр. 2019 г. в
> > > 
> > > 01:58,
> > > > > > > > > > oignatenko <
> > > > > > > > > > > > > > > > > > > > > > oignatenko@gridgain.com
> > > > > > > > > > > > > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Maxim,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe that whatever
> > > 
> > > style checks
> > > > > > > > > > we establish at
> > > > > > > > > > > > > > > > > > > > > > Teamcity, we
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > better
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > take care of making it
> > > 
> > > easy for
> > > > > > > > > > developers to find and
> > > > > > > > > > > > > > > > > > > > fix
> > > > > > > > > > > > > > > > > > > > > > > > > violations
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > their typical dev
> > > 
> > > environment (for
> > > > > > > > > > Ignite this means, in
> > > > > > > > > > > > > > > > > > > > > > IDEA). I
> > > > > > > > > > > > > > > > > > > > > > > > > > > > think
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > is important that
> > > 
> > > developers can
> > > > > > > > > > maintain 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
> > > > > > > > > > just 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
> > > > > > > > > > checkstyle - I
> > > > > > > > > > > > > > > > > > > > recommend
> > > > > > > > > > > > > > > > > > > > > > keeping
> > > > > > > > > > > > > > > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > config file somewhere
> > > 
> > > in the project
> > > > > > > > > > under version
> > > > > > > > > > > > > > > > > > > > control.
> > > > > > > > > > > > > > > > > > > > > > I
> > > > > > > > > > > > > > > > > > > > > > > > > used to
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > maintain such a shared
> > > 
> > > style config
> > > > > > > > > > at one of past jobs
> > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > after
> > > > > > > > > > > > > > > > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > experimenting it turned
> > > 
> > > out most
> > > > > > > > > > convenient to have it
> > > > > > > > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > > > > > > > way -
> > > > > > > > > > > > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > developers could easily
> > > 
> > > assess and
> > > > > > > > > > discuss style
> > > > > > > > > > > > > > > > > > > > settings
> > > > > > > > > > > > > > > > > > > > > > and keep
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > track
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > changes in these. (note
> > > 
> > > how Kafka
> > > > > > > > > > folks 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
> > > > > > > > > > community members.
> > > > > > > > > > > > > > > > > > > > > > Moreover, this
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > suite is no longer
> > > 
> > > checks rules we
> > > > > > > > > > previously
> > > > > > > > > > > > > > > > > > > > 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
> > > > > > > > > > consider the Apache Kafka
> > > > > > > > > > > > > > > > > > > > > > code
> > > > > > > > > > > > > > > > > > > > > > > > > style
> > > > > > > > > > > > > > > > > > > > > > > > > > > > [5]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > way and configure for
> > > 
> > > the Ignite
> > > > > > > > > > project a
> > > > > > > > > > > > > > > > > > > > > > > > > maven-checkstyle-plugin
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > with its own maven
> > > 
> > > profile and run
> > > > > > > > > > it simultaneously
> > > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > > other
> > > > > > > > > > > > > > > > > > > > > > > > > TC.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > We
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > can also enable the
> > > 
> > > previously
> > > > > > > > > > configured inspection
> > > > > > > > > > > > > > > > > > > > > > rules, so no
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > coding style
> > > 
> > > violations will be
> > > > > > > > > > missed.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I see some advantages
> > > 
> > > of using a
> > > > > > > > > > maven plugin:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - an IDE agnostic way
> > > 
> > > for code checks
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - can be used with
> > > 
> > > different CI and
> > > > > > > > > > build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [2]
> > > > > > > > > > 
> > > > > > > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [3]
> > > 
> > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [4]
> > > > > > > > > > 
> > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [5]
> > > 
> > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 21 Dec 2018 at
> > > 
> > > 16:03, Petr
> > > > > > > > > > Ivanov &lt;
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > mr.weider@
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > &gt; wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It seems there is bug
> > > 
> > > in latest
> > > > > > > > > > 2018.2 TeamCity
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bug is filed [1]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > 
> > > > > > > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 19 Dec 2018, at
> > > 
> > > 11:31, Petr
> > > > > > > > > > Ivanov &lt;
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > mr.weider@
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > &gt; wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Investigating
> > > 
> > > problem, stand by.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 18 Dec 2018, at
> > > 
> > > 19:41, Dmitriy
> > > > > > > > > > Pavlov &lt;
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > dpavlov@
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > &gt; 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
> > > > > > > > > > next 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
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > --
> > > > > > > > > > Best regards,
> > > > > > > > > > Ivan Pavlukhin
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > 
> > > > 
> > > > 
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > 
> > > 
> > > 
> > > --
> > > Best Regards, Vyacheslav D.
> > > 
> 
> 
> 

Re: Code inspection

[Павлухин Иван <vo...@gmail.com>]

Hi Nikolay,

Great, another one nice step to clean code.

I scrolled down the commit [1] and have couple of observations:
1. According to our code style agreements each class member should be
separated by 1 empty line. As I see there were many places where it
was not followed for class fields. E.g. empty lines were added for a
code snippet below. For me fields without extra empty lines between
them look fine. Of course, it is a question of our agreements. So, we
can either permit no empty lines for fields or enforce empty line for
each class member.
private static class FlaggedCacheOperationCallable implements
Callable<GridRestResponse>, Serializable {
/** */
private static final long serialVersionUID = 0L;
/** */
private final String cacheName;
/** */
private final Set<GridClientCacheFlag> cacheFlags;

2. Also I noticed an empty line between a method signature and a first
statement in the method in some places, e.g. [2]. Can/should we
enforce no empty lines there?

And one aside observation (in the same file), it has class fields
without a javadoc [3]. Do not our code check jobs enforce javadoc for
fields?

[1] https://github.com/apache/ignite/commit/d63f4d3569dcb387394d367a7f00aaf35f1b288e
[2] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/io/GridReversedLinesFileReader.java#L154
[3] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/io/GridReversedLinesFileReader.java#L35

вс, 2 июн. 2019 г. в 22:00, Nikolay Izhikov <ni...@apache.org>:
>
> Hello, Igniters.
>
> 1. I've added "EmptyLineSeparator" inspection, according to our code style
> [1]
> 2. I've fixed all current code style violations.
>
> Please, see my commit [2]
>
> You may want to merge these changes to your private repos.
>
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines
> [2]
> https://github.com/apache/ignite/commit/d63f4d3569dcb387394d367a7f00aaf35f1b288e
>
>
>
>
> вт, 23 апр. 2019 г. в 10:45, Vyacheslav Daradur <da...@gmail.com>:
>
> > Also, I excluded "IntelliJ IDEA Inspections" from RunAll and marked it
> > as "~[Excluded]".
> >
> > On Tue, Apr 23, 2019 at 12:25 AM Vyacheslav Daradur <da...@gmail.com>
> > wrote:
> > >
> > > Maxim, I merged your changes to master.
> > >
> > > 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.
> > >
> > > Please check that it works as expected once again and announce new
> > > requirements in a separate thread to avoid confusion of community.
> > >
> > > cc Petr, Pavel (JFYI)
> > >
> > > [1]
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=buildTypeBranches
> > >
> > > On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur <da...@gmail.com>
> > wrote:
> > > >
> > > > Maxim,
> > > >
> > > > I left some comments in Jira, let's resolve them and I'll assist you
> > > > with merge and TC configuring.
> > > >
> > > > On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com>
> > wrote:
> > > > >
> > > > > Vyacheslav,
> > > > >
> > > > > Thank you for your interest in making Ignite coding style better.
> > > > >
> > > > > 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.
> > > > >
> > > > > 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.
> > > > >
> > > > > 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;
> > > > >
> > > > > On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <
> > daradurvs@gmail.com> wrote:
> > > > > >
> > > > > > Maxim,
> > > > > >
> > > > > > I looked through the PR and it looks good to me in general.
> > > > > >
> > > > > > The only question how it's planned to maintain check styles in 2
> > > > > > different configurations, for IDEA and check style plugin?
> > > > > >
> > > > > > On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <
> > maxmuzaf@gmail.com> wrote:
> > > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > 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).
> > > > > > >
> > > > > > > JIRA: IGNITE-11277 [1]
> > > > > > > PR: [3]
> > > > > > > Upsource: [4]
> > > > > > >
> > > > > > > How can take a look?
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > > [2]
> > http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
> > > > > > > [3] https://github.com/apache/ignite/pull/6119
> > > > > > > [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
> > > > > > >
> > > > > > > On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org>
> > wrote:
> > > > > > > >
> > > > > > > > Hi Igniters,
> > > > > > > >
> > > > > > > > I see that a new TeamCity is released: Version: 2018.2.3.
> > > > > > > >
> > > > > > > > Probably it could solve recently introduced problem related to:
> > > > > > > > Unexpected error during build messages processing in TeamCity;
> > > > > > > >
> > > > > > > > Peter I., could you please check?
> > > > > > > >
> > > > > > > > Sincerely,
> > > > > > > > Dmitriy Pavlov
> > > > > > > >
> > > > > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <
> > vololo100@gmail.com>:
> > > > > > > >
> > > > > > > > > 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
> > > > > > > > > today.
> > > > > > > > >
> > > > > > > > > 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.
> > > > > > > > >
> > > > > > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <
> > vololo100@gmail.com>:
> > > > > > > > > >
> > > > > > > > > > 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.
> > > > > > > > > >
> > > > > > > > > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <
> > nizhikov@apache.org>:
> > > > > > > > > > >
> > > > > > > > > > > +1 to enable code style checks in compile time.
> > > > > > > > > > >
> > > > > > > > > > > We can add option to disable maven codestyle profile
> > with some
> > > > > > > > > environment variable.
> > > > > > > > > > >
> > > > > > > > > > > Anyone who want violate common project rules in their
> > local branch can
> > > > > > > > > set this variable and write some nasty code before push :)
> > > > > > > > > > >
> > > > > > > > > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <
> > maxmuzaf@gmail.com>:
> > > > > > > > > > >>
> > > > > > > > > > >> 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
> > > > > > > > > build stage.
> > > > > > > > > > >> - increases a bit the build time procedure
> > > > > > > > > > >> - require additional operations to switch it off for
> > prototyping
> > > > > > > > > branches
> > > > > > > > > > >>
> > > > > > > > > > >> + do not require TC.Bot visa if someone of the
> > community doesn't use
> > > > > > > > > it
> > > > > > > > > > >> + 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
> > > > > > > > > needs.
> > > > > > > > > > >>
> > > > > > > > > > >> ---
> > > > > > > > > > >>
> > > > > > > > > > >> 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+Contribute#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, Павлухин Иван <
> > vololo100@gmail.com>
> > > > > > > > > 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:
> > > > > > > > > > >> > ====Quoted text====
> > > > > > > > > > >> > 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.
> > > > > > > > > > >> > 2. Style check takes some time. With simple checks it
> > is almost
> > > > > > > > > > >> > negligible. But it can grow if more checks are
> > involved.
> > > > > > > > > > >> > ====End of quoted text====
> > > > > > > > > > >> >
> > > > > > > > > > >> > Some clarifications. 1 is about running from IDEA
> > first. 2 is
> > > > > > > > > related
> > > > > > > > > > >> > to opinions that we should involve much more checks,
> > e.g. using
> > > > > > > > > > >> > abbreviations.
> > > > > > > > > > >> >
> > > > > > > > > > >> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <
> > maxmuzaf@gmail.com>:
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Ivan,
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Let's take a look at all the options we have
> > (ordered by the
> > > > > > > > > frequency 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
> > > > > > > > > checkstyle plugin is used in the <build> 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.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Back to our use cases:
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > 1. For checking the ready to merge branches we will
> > fail the
> > > > > > > > > ~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.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > 2. For the prototyping branches, you can turn off
> > checkstyle in
> > > > > > > > > your 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
> > > > > > > > > checkstyle enabled profile. The common build action as `mvn
> > clean install
> > > > > > > > > -DskipTests` will activate the profile.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > 4. The checkstyle profile can be disabled
> > explicitly on TC by
> > > > > > > > > specifying -P !checkstyle option. A don't see any use cases
> > of it, but it's
> > > > > > > > > completely doable.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Please, correct me if I've missed something.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > I propose to merge PR [1] as it is, with the
> > configured set of
> > > > > > > > > rules.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > [1] https://github.com/apache/ignite/pull/6119
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <
> > vololo100@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > >> > >>
> > > > > > > > > > >> > >> Maxim,
> > > > > > > > > > >> > >>
> > > > > > > > > > >> > >> I like an idea of being IDE agnostic. I am ok with
> > currently
> > > > > > > > > enabled
> > > > > > > > > > >> > >> 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
> > > > > > > > > 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.
> > > > > > > > > > >> > >> 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"
> > > > > > > > > which I
> > > > > > > > > > >> > >> think is quite useful.
> > > > > > > > > > >> > >>
> > > > > > > > > > >> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <
> > maxmuzaf@gmail.com
> > > > > > > > > >:
> > > > > > > > > > >> > >> >
> > > > > > > > > > >> > >> > Ivan,
> > > > > > > > > > >> > >> >
> > > > > > > > > > >> > >> > I like that Jetbrains inspections are integrated
> > with IDE and
> > > > > > > > > TC 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
> > > > > > > > > with code
> > > > > > > > > > >> > >> > style checking. I've checked popular java
> > projects: hadoop,
> > > > > > > > > kafka,
> > > > > > > > > > >> > >> > spark, hive, netty. All of them are using
> > > > > > > > > maven-checkstyle-plugin in
> > > > > > > > > > >> > >> > their <build> 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
> > > > > > > > > and
> > > > > > > > > > >> > >> > SizeReplaceableByIsEmpty (all code style checks
> > [5]). Propose
> > > > > > > > > to 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-1018
> > > > > > > > > > >> > >> > [4]
> > > > > > > > >
> > https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > > > > > > > > > >> > >> > [5]
> > http://checkstyle.sourceforge.net/checks.html
> > > > > > > > > > >> > >> >
> > > > > > > > > > >> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> > > > > > > > > vololo100@gmail.com> 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
> > > > > > > > > checkstyle
> > > > > > > > > > >> > >> > > plugin? Is it integrated into IDEA out of box?
> > As I got it
> > > > > > > > > additional
> > > > > > > > > > >> > >> > > 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
> > > > > > > > > visa. Visa
> > > > > > > > > > >> > >> > > includes result from running inspections job.
> > > > > > > > > > >> > >> > >
> > > > > > > > > > >> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> > > > > > > > > nizhikov@apache.org>:
> > > > > > > > > > >> > >> > > >
> > > > > > > > > > >> > >> > > > 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.
> > > > > > > > > > >> > >> > > >
> > > > > > > > > > >> > >> > > >
> > > > > > > > > > >> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> > > > > > > > > vololo100@gmail.com>:
> > > > > > > > > > >> > >> > > >
> > > > > > > > > > >> > >> > > > > Nikolay,
> > > > > > > > > > >> > >> > > > >
> > > > > > > > > > >> > >> > > > > > Should the community spend TC resources
> > for  prototype?
> > > > > > > > > > >> > >> > > > > Why not? I think it is not bad idea to run
> > all tests
> > > > > > > > > against 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
> > > > > > > > > with other
> > > > > > > > > > >> > >> > > > > Igniters. I think it is the cheapest way
> > to check the
> > > > > > > > > idea because the
> > > > > > > > > > >> > >> > > > > check is fully automated. Requiring a
> > human feedback is
> > > > > > > > > much 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
> > > > > > > > > skipping tests
> > > > > > > > > > >> > >> > > > > execution if inspections detect a problem?
> > > > > > > > > > >> > >> > > > >
> > > > > > > > > > >> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay
> > Izhikov <
> > > > > > > > > nizhikov@apache.org>:
> > > > > > > > > > >> > >> > > > > >
> > > > > > > > > > >> > >> > > > > > 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
> > > > > > > > > prototype.
> > > > > > > > > > >> > >> > > > > >
> > > > > > > > > > >> > >> > > > > > 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?
> > > > > > > > > > >> > >> > > > > >
> > > > > > > > > > >> > >> > > > > >
> > > > > > > > > > >> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин
> > Иван <
> > > > > > > > > vololo100@gmail.com>:
> > > > > > > > > > >> > >> > > > > >
> > > > > > > > > > >> > >> > > > > > > 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
> > > > > > > > > outline 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
> > > > > > > > > that message).
> > > > > > > > > > >> > >> > > > > > >
> > > > > > > > > > >> > >> > > > > > > We have a document defining code style
> > which every
> > > > > > > > > contributor should
> > > > > > > > > > >> > >> > > > > > > follow [1]. And many points can be
> > checked
> > > > > > > > > automatically. Personally,
> > > > > > > > > > >> > >> > > > > > > I do not see much need in writing good
> > javadocs for
> > > > > > > > > prototype. Why
> > > > > > > > > > >> > >> > > > > > > should I stub it to be able run any
> > build on TC?
> > > > > > > > > > >> > >> > > > > > >
> > > > > > > > > > >> > >> > > > > > > Also, we a have a review process which
> > should be
> > > > > > > > > applied to every
> > > > > > > > > > >> > >> > > > > > > patch. Partially it is described in
> > [2]. And due to
> > > > > > > > > this process every
> > > > > > > > > > >> > >> > > > > > > patch should not introduce new
> > failures on TC. So,
> > > > > > > > > the patch should
> > > > > > > > > > >> > >> > > > > > > not be merged if inspections failed.
> > > > > > > > > > >> > >> > > > > > >
> > > > > > > > > > >> > >> > > > > > > P.S. Something more about prototypes
> > and production
> > > > > > > > > code. There is a
> > > > > > > > > > >> > >> > > > > > > common bad practice in software
> > engineering. It is
> > > > > > > > > turning prototypes
> > > > > > > > > > >> > >> > > > > > > into production code. Often it is much
> > faster to
> > > > > > > > > create a prototype by
> > > > > > > > > > >> > >> > > > > > > price of violating some rules of
> > writing "clean
> > > > > > > > > code". And often
> > > > > > > > > > >> > >> > > > > > > prototype after successful piloting is
> > turned into
> > > > > > > > > production code.
> > > > > > > > > > >> > >> > > > > > > And it is very easy in practice to
> > keep some pieces
> > > > > > > > > of 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"
> > > > > > > > > from the beginning.
> > > > > > > > > > >> > >> > > > > > > So, only ideas are taken from the
> > prototype and a
> > > > > > > > > code is fully
> > > > > > > > > > >> > >> > > > > > > rewritten.
> > > > > > > > > > >> > >> > > > > > >
> > > > > > > > > > >> > >> > > > > > > [1]
> > > > > > > > > > >> > >> > > > >
> > > > > > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > > > > > > > >> > >> > > > > > > [2]
> > > > > > > > > > >> > >> > > > >
> > > > > > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > > > > > > > >> > >> > > > > > >
> > > > > > > > > > >> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim
> > Muzafarov <
> > > > > > > > > maxmuzaf@gmail.com>:
> > > > > > > > > > >> > >> > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > Ivan,
> > > > > > > > > > >> > >> > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > As the first implementation of this
> > addition, I'd
> > > > > > > > > prefer to make it
> > > > > > > > > > >> > >> > > > > > > > working like _Licenses Headers_
> > suite check. It
> > > > > > > > > will fail when some
> > > > > > > > > > >> > >> > > > > of
> > > > > > > > > > >> > >> > > > > > > > the code style checks violated.
> > Moreover, these
> > > > > > > > > licenses header
> > > > > > > > > > >> > >> > > > > checks
> > > > > > > > > > >> > >> > > > > > > > can be included in the checkstyle
> > plugin
> > > > > > > > > configuration.
> > > > > > > > > > >> > >> > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > In general, I'd prefer to have a
> > compilation fail
> > > > > > > > > error with code
> > > > > > > > > > >> > >> > > > > > > > style checks and after we will get a
> > stable
> > > > > > > > > checkstyle suite I
> > > > > > > > > > >> > >> > > > > propose
> > > > > > > > > > >> > >> > > > > > > > to change it in a "compilation
> > error" way. If we
> > > > > > > > > are talking about
> > > > > > > > > > >> > >> > > > > the
> > > > > > > > > > >> > >> > > > > > > > coding style convenient for most of
> > the community
> > > > > > > > > members I see no
> > > > > > > > > > >> > >> > > > > > > > difference with coding sketches or
> > > > > > > > > production-ready branches equally.
> > > > > > > > > > >> > >> > > > > > > > Indeed, no one will be against
> > unused imports [or
> > > > > > > > > spaces 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() == 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 <
> > > > > > > > > nizhikov@apache.org>
> > > > > > > > > > >> > >> > > > > > > wrote:
> > > > > > > > > > >> > >> > > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > > Actually, I dont see anything
> > wrong with failing
> > > > > > > > > *compilation*
> > > > > > > > > > >> > >> > > > > task.
> > > > > > > > > > >> > >> > > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > > I think one should use project
> > code style for
> > > > > > > > > everyday 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?
> > > > > > > > > > >> > >> > > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr
> > Ivanov
> > > > > > > > > mr.weider@gmail.com:
> > > > > > > > > > >> > >> > > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > > > I guess that was about failing
> > build
> > > > > > > > > configuration with
> > > > > > > > > > >> > >> > > > > Checkstype,
> > > > > > > > > > >> > >> > > > > > > not
> > > > > > > > > > >> > >> > > > > > > > > > compilation build itself.
> > > > > > > > > > >> > >> > > > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03,
> > Павлухин Иван <
> > > > > > > > > vololo100@gmail.com>
> > > > > > > > > > >> > >> > > > > > > wrote:
> > > > > > > > > > >> > >> > > > > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > > > > Folks,
> > > > > > > > > > >> > >> > > > > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > > > > Are you going to fail job
> > compiling Ignite
> > > > > > > > > sources [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
> > > > > > > > > convenient to skip some
> > > > > > > > > > >> > >> > > > > style
> > > > > > > > > > >> > >> > > > > > > > > > > requirements for such sketches
> > (e.g. well
> > > > > > > > > formed javadocs).
> > > > > > > > > > >> > >> > > > > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > > > > [1]
> > > > > > > > > > >> > >> > > > > > > > > >
> > > > > > > > > > >> > >> > > > > > >
> > > > > > > > > > >> > >> > > > >
> > > > > > > > >
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > > > > > > >> > >> > > > > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38,
> > Nikolay
> > > > > > > > > Izhikov <
> > > > > > > > > > >> > >> > > > > nizhikov@apache.org
> > > > > > > > > > >> > >> > > > > > > >:
> > > > > > > > > > >> > >> > > > > > > > > > >>
> > > > > > > > > > >> > >> > > > > > > > > > >> Petr, we should have 1
> > configuration for
> > > > > > > > > project, may be 1
> > > > > > > > > > >> > >> > > > > > > configuration
> > > > > > > > > > >> > >> > > > > > > > > > >> per programming language.
> > > > > > > > > > >> > >> > > > > > > > > > >>
> > > > > > > > > > >> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33
> > Petr Ivanov
> > > > > > > > > mr.weider@gmail.com:
> > > > > > > > > > >> > >> > > > > > > > > > >>
> > > > > > > > > > >> > >> > > > > > > > > > >>> I was asking about how many
> > build
> > > > > > > > > configuration is intended?
> > > > > > > > > > >> > >> > > > > One
> > > > > > > > > > >> > >> > > > > > > for
> > > > > > > > > > >> > >> > > > > > > > > > all
> > > > > > > > > > >> > >> > > > > > > > > > >>> and multiple per module?
> > > > > > > > > > >> > >> > > > > > > > > > >>>
> > > > > > > > > > >> > >> > > > > > > > > > >>> With IDEA inspections it was
> > going to be
> > > > > > > > > build 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
> > > > > > > > > build task? And each
> > > > > > > > > > >> > >> > > > > > > module
> > > > > > > > > > >> > >> > > > > > > > > > builds
> > > > > > > > > > >> > >> > > > > > > > > > >>>> when it required? If yes,
> > then I propose
> > > > > > > > > to create a task
> > > > > > > > > > >> > >> > > > > like
> > > > > > > > > > >> > >> > > > > > > > > > "Licence
> > > > > > > > > > >> > >> > > > > > > > > > >>>> check" which will be run
> > for every patch.
> > > > > > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>> My point is that violation
> > of codestyle
> > > > > > > > > should be treated as
> > > > > > > > > > >> > >> > > > > > > hard as
> > > > > > > > > > >> > >> > > > > > > > > > >>>> compile error.
> > > > > > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16
> > Petr Ivanov
> > > > > > > > > mr.weider@gmail.com
> > > > > > > > > > >> > >> > > > > :
> > > > > > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>> Is build configuration
> > Inspections
> > > > > > > > > [Core] meant to
> > > > > > > > > > >> > >> > > > > transform
> > > > > > > > > > >> > >> > > > > > > into
> > > > > > > > > > >> > >> > > > > > > > > > single
> > > > > > > > > > >> > >> > > > > > > > > > >>>>> all-modules check build
> > configuration
> > > > > > > > > (without module
> > > > > > > > > > >> > >> > > > > > > subdivision)?
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02,
> > Nikolay
> > > > > > > > > Izhikov <
> > > > > > > > > > >> > >> > > > > > > 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/1065-checkstyle-idea
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>> I propose do the
> > following:
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>> 1. Migrate current checks
> > to checkstyle.
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>> 2. Apply checks to all
> > Ignite modules.
> > > > > > > > > Currently, 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
> > > > > > > > > Apache Ignite"
> > > > > > > > > > >> > >> > > > > suite.
> > > > > > > > > > >> > >> > > > > > > Ignite
> > > > > > > > > > >> > >> > > > > > > > > > has
> > > > > > > > > > >> > >> > > > > > > > > > >>>>> to
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>> fail to build if patch
> > violates
> > > > > > > > > codestyle.
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в
> > 07:54, Павлухин
> > > > > > > > > Иван <
> > > > > > > > > > >> > >> > > > > > > vololo100@gmail.com>:
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>> Hi,
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>> I also think that some
> > warning from
> > > > > > > > > IDEA that some code
> > > > > > > > > > >> > >> > > > > > > style rule
> > > > > > > > > > >> > >> > > > > > > > > > is
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>> violated is a must-have.
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в
> > 01:58,
> > > > > > > > > oignatenko <
> > > > > > > > > > >> > >> > > > > > > oignatenko@gridgain.com
> > > > > > > > > > >> > >> > > > > > > > > > >:
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> I believe that whatever
> > style checks
> > > > > > > > > we establish at
> > > > > > > > > > >> > >> > > > > > > Teamcity, we
> > > > > > > > > > >> > >> > > > > > > > > > >>>>> better
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> take care of making it
> > easy for
> > > > > > > > > developers to find and
> > > > > > > > > > >> > >> > > > > fix
> > > > > > > > > > >> > >> > > > > > > > > > violations
> > > > > > > > > > >> > >> > > > > > > > > > >>>>> in
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> their typical dev
> > environment (for
> > > > > > > > > Ignite this means, in
> > > > > > > > > > >> > >> > > > > > > IDEA). I
> > > > > > > > > > >> > >> > > > > > > > > > >>> think
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>> it
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> is important that
> > developers can
> > > > > > > > > maintain 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
> > > > > > > > > just 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
> > > > > > > > > checkstyle - I
> > > > > > > > > > >> > >> > > > > recommend
> > > > > > > > > > >> > >> > > > > > > keeping
> > > > > > > > > > >> > >> > > > > > > > > > >>> its
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> config file somewhere
> > in the project
> > > > > > > > > under version
> > > > > > > > > > >> > >> > > > > control.
> > > > > > > > > > >> > >> > > > > > > I
> > > > > > > > > > >> > >> > > > > > > > > > used to
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> maintain such a shared
> > style config
> > > > > > > > > at one of past jobs
> > > > > > > > > > >> > >> > > > > and
> > > > > > > > > > >> > >> > > > > > > after
> > > > > > > > > > >> > >> > > > > > > > > > >>> some
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> experimenting it turned
> > out most
> > > > > > > > > convenient to have it
> > > > > > > > > > >> > >> > > > > this
> > > > > > > > > > >> > >> > > > > > > way -
> > > > > > > > > > >> > >> > > > > > > > > > so
> > > > > > > > > > >> > >> > > > > > > > > > >>>>> that
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> developers could easily
> > assess and
> > > > > > > > > discuss style
> > > > > > > > > > >> > >> > > > > settings
> > > > > > > > > > >> > >> > > > > > > and keep
> > > > > > > > > > >> > >> > > > > > > > > > >>>>> track
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>> of
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> changes in these. (note
> > how Kafka
> > > > > > > > > folks 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
> > > > > > > > > community members.
> > > > > > > > > > >> > >> > > > > > > Moreover, this
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> suite is no longer
> > checks rules we
> > > > > > > > > previously
> > > > > > > > > > >> > >> > > > > 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
> > > > > > > > > consider the Apache Kafka
> > > > > > > > > > >> > >> > > > > > > code
> > > > > > > > > > >> > >> > > > > > > > > > style
> > > > > > > > > > >> > >> > > > > > > > > > >>> [5]
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> way and configure for
> > the Ignite
> > > > > > > > > project a
> > > > > > > > > > >> > >> > > > > > > > > > maven-checkstyle-plugin
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> with its own maven
> > profile and run
> > > > > > > > > it simultaneously
> > > > > > > > > > >> > >> > > > > with
> > > > > > > > > > >> > >> > > > > > > other
> > > > > > > > > > >> > >> > > > > > > > > > TC.
> > > > > > > > > > >> > >> > > > > > > > > > >>> We
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> can also enable the
> > previously
> > > > > > > > > configured inspection
> > > > > > > > > > >> > >> > > > > > > rules, so no
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> coding style
> > violations will be
> > > > > > > > > missed.
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> I see some advantages
> > of using a
> > > > > > > > > maven plugin:
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way
> > for code checks
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> - can be used with
> > different CI and
> > > > > > > > > build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [2]
> > > > > > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [3]
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>
> > > > > > > > > > >> > >> > > > > > > > > >
> > > > > > > > > > >> > >> > > > > > >
> > > > > > > > > > >> > >> > > > >
> > > > > > > > >
> > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [4]
> > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [5]
> > > > > > > > > > >> > >> > > > >
> > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at
> > 16:03, Petr
> > > > > > > > > Ivanov &lt;
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug
> > in latest
> > > > > > > > > 2018.2 TeamCity
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>> [1]
> > > > > > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at
> > 11:31, Petr
> > > > > > > > > Ivanov &lt;
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>> Investigating
> > problem, stand by.
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at
> > 19:41, Dmitriy
> > > > > > > > > Pavlov &lt;
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> dpavlov@
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; 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
> > > > > > > > > next 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best regards,
> > > > > > > > > Ivan Pavlukhin
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >



-- 
Best regards,
Ivan Pavlukhin

Re: Code inspection

[Nikolay Izhikov <ni...@apache.org>]

Hello, Igniters.

1. I've added "EmptyLineSeparator" inspection, according to our code style
[1]
2. I've fixed all current code style violations.

Please, see my commit [2]

You may want to merge these changes to your private repos.

[1]
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines
[2]
https://github.com/apache/ignite/commit/d63f4d3569dcb387394d367a7f00aaf35f1b288e




вт, 23 апр. 2019 г. в 10:45, Vyacheslav Daradur <da...@gmail.com>:

> Also, I excluded "IntelliJ IDEA Inspections" from RunAll and marked it
> as "~[Excluded]".
>
> On Tue, Apr 23, 2019 at 12:25 AM Vyacheslav Daradur <da...@gmail.com>
> wrote:
> >
> > Maxim, I merged your changes to master.
> >
> > 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.
> >
> > Please check that it works as expected once again and announce new
> > requirements in a separate thread to avoid confusion of community.
> >
> > cc Petr, Pavel (JFYI)
> >
> > [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=buildTypeBranches
> >
> > On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur <da...@gmail.com>
> wrote:
> > >
> > > Maxim,
> > >
> > > I left some comments in Jira, let's resolve them and I'll assist you
> > > with merge and TC configuring.
> > >
> > > On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com>
> wrote:
> > > >
> > > > Vyacheslav,
> > > >
> > > > Thank you for your interest in making Ignite coding style better.
> > > >
> > > > 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.
> > > >
> > > > 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.
> > > >
> > > > 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;
> > > >
> > > > On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <
> daradurvs@gmail.com> wrote:
> > > > >
> > > > > Maxim,
> > > > >
> > > > > I looked through the PR and it looks good to me in general.
> > > > >
> > > > > The only question how it's planned to maintain check styles in 2
> > > > > different configurations, for IDEA and check style plugin?
> > > > >
> > > > > On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <
> maxmuzaf@gmail.com> wrote:
> > > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > 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).
> > > > > >
> > > > > > JIRA: IGNITE-11277 [1]
> > > > > > PR: [3]
> > > > > > Upsource: [4]
> > > > > >
> > > > > > How can take a look?
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > [2]
> http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
> > > > > > [3] https://github.com/apache/ignite/pull/6119
> > > > > > [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
> > > > > >
> > > > > > On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org>
> wrote:
> > > > > > >
> > > > > > > Hi Igniters,
> > > > > > >
> > > > > > > I see that a new TeamCity is released: Version: 2018.2.3.
> > > > > > >
> > > > > > > Probably it could solve recently introduced problem related to:
> > > > > > > Unexpected error during build messages processing in TeamCity;
> > > > > > >
> > > > > > > Peter I., could you please check?
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <
> vololo100@gmail.com>:
> > > > > > >
> > > > > > > > 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
> > > > > > > > today.
> > > > > > > >
> > > > > > > > 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.
> > > > > > > >
> > > > > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <
> vololo100@gmail.com>:
> > > > > > > > >
> > > > > > > > > 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.
> > > > > > > > >
> > > > > > > > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <
> nizhikov@apache.org>:
> > > > > > > > > >
> > > > > > > > > > +1 to enable code style checks in compile time.
> > > > > > > > > >
> > > > > > > > > > We can add option to disable maven codestyle profile
> with some
> > > > > > > > environment variable.
> > > > > > > > > >
> > > > > > > > > > Anyone who want violate common project rules in their
> local branch can
> > > > > > > > set this variable and write some nasty code before push :)
> > > > > > > > > >
> > > > > > > > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <
> maxmuzaf@gmail.com>:
> > > > > > > > > >>
> > > > > > > > > >> 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
> > > > > > > > build stage.
> > > > > > > > > >> - increases a bit the build time procedure
> > > > > > > > > >> - require additional operations to switch it off for
> prototyping
> > > > > > > > branches
> > > > > > > > > >>
> > > > > > > > > >> + do not require TC.Bot visa if someone of the
> community doesn't use
> > > > > > > > it
> > > > > > > > > >> + 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
> > > > > > > > needs.
> > > > > > > > > >>
> > > > > > > > > >> ---
> > > > > > > > > >>
> > > > > > > > > >> 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+Contribute#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, Павлухин Иван <
> vololo100@gmail.com>
> > > > > > > > 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:
> > > > > > > > > >> > ====Quoted text====
> > > > > > > > > >> > 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.
> > > > > > > > > >> > 2. Style check takes some time. With simple checks it
> is almost
> > > > > > > > > >> > negligible. But it can grow if more checks are
> involved.
> > > > > > > > > >> > ====End of quoted text====
> > > > > > > > > >> >
> > > > > > > > > >> > Some clarifications. 1 is about running from IDEA
> first. 2 is
> > > > > > > > related
> > > > > > > > > >> > to opinions that we should involve much more checks,
> e.g. using
> > > > > > > > > >> > abbreviations.
> > > > > > > > > >> >
> > > > > > > > > >> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <
> maxmuzaf@gmail.com>:
> > > > > > > > > >> > >
> > > > > > > > > >> > > Ivan,
> > > > > > > > > >> > >
> > > > > > > > > >> > > Let's take a look at all the options we have
> (ordered by the
> > > > > > > > frequency 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
> > > > > > > > checkstyle plugin is used in the <build> 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.
> > > > > > > > > >> > >
> > > > > > > > > >> > > Back to our use cases:
> > > > > > > > > >> > >
> > > > > > > > > >> > > 1. For checking the ready to merge branches we will
> fail the
> > > > > > > > ~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.
> > > > > > > > > >> > >
> > > > > > > > > >> > > 2. For the prototyping branches, you can turn off
> checkstyle in
> > > > > > > > your 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
> > > > > > > > checkstyle enabled profile. The common build action as `mvn
> clean install
> > > > > > > > -DskipTests` will activate the profile.
> > > > > > > > > >> > >
> > > > > > > > > >> > > 4. The checkstyle profile can be disabled
> explicitly on TC by
> > > > > > > > specifying -P !checkstyle option. A don't see any use cases
> of it, but it's
> > > > > > > > completely doable.
> > > > > > > > > >> > >
> > > > > > > > > >> > > Please, correct me if I've missed something.
> > > > > > > > > >> > >
> > > > > > > > > >> > > I propose to merge PR [1] as it is, with the
> configured set of
> > > > > > > > rules.
> > > > > > > > > >> > >
> > > > > > > > > >> > > [1] https://github.com/apache/ignite/pull/6119
> > > > > > > > > >> > >
> > > > > > > > > >> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <
> vololo100@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > >> > >>
> > > > > > > > > >> > >> Maxim,
> > > > > > > > > >> > >>
> > > > > > > > > >> > >> I like an idea of being IDE agnostic. I am ok with
> currently
> > > > > > > > enabled
> > > > > > > > > >> > >> 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
> > > > > > > > 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.
> > > > > > > > > >> > >> 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"
> > > > > > > > which I
> > > > > > > > > >> > >> think is quite useful.
> > > > > > > > > >> > >>
> > > > > > > > > >> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <
> maxmuzaf@gmail.com
> > > > > > > > >:
> > > > > > > > > >> > >> >
> > > > > > > > > >> > >> > Ivan,
> > > > > > > > > >> > >> >
> > > > > > > > > >> > >> > I like that Jetbrains inspections are integrated
> with IDE and
> > > > > > > > TC 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
> > > > > > > > with code
> > > > > > > > > >> > >> > style checking. I've checked popular java
> projects: hadoop,
> > > > > > > > kafka,
> > > > > > > > > >> > >> > spark, hive, netty. All of them are using
> > > > > > > > maven-checkstyle-plugin in
> > > > > > > > > >> > >> > their <build> 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
> > > > > > > > and
> > > > > > > > > >> > >> > SizeReplaceableByIsEmpty (all code style checks
> [5]). Propose
> > > > > > > > to 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-1018
> > > > > > > > > >> > >> > [4]
> > > > > > > >
> https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > > > > > > > > >> > >> > [5]
> http://checkstyle.sourceforge.net/checks.html
> > > > > > > > > >> > >> >
> > > > > > > > > >> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> > > > > > > > vololo100@gmail.com> 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
> > > > > > > > checkstyle
> > > > > > > > > >> > >> > > plugin? Is it integrated into IDEA out of box?
> As I got it
> > > > > > > > additional
> > > > > > > > > >> > >> > > 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
> > > > > > > > visa. Visa
> > > > > > > > > >> > >> > > includes result from running inspections job.
> > > > > > > > > >> > >> > >
> > > > > > > > > >> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> > > > > > > > nizhikov@apache.org>:
> > > > > > > > > >> > >> > > >
> > > > > > > > > >> > >> > > > 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.
> > > > > > > > > >> > >> > > >
> > > > > > > > > >> > >> > > >
> > > > > > > > > >> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> > > > > > > > vololo100@gmail.com>:
> > > > > > > > > >> > >> > > >
> > > > > > > > > >> > >> > > > > Nikolay,
> > > > > > > > > >> > >> > > > >
> > > > > > > > > >> > >> > > > > > Should the community spend TC resources
> for  prototype?
> > > > > > > > > >> > >> > > > > Why not? I think it is not bad idea to run
> all tests
> > > > > > > > against 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
> > > > > > > > with other
> > > > > > > > > >> > >> > > > > Igniters. I think it is the cheapest way
> to check the
> > > > > > > > idea because the
> > > > > > > > > >> > >> > > > > check is fully automated. Requiring a
> human feedback is
> > > > > > > > much 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
> > > > > > > > skipping tests
> > > > > > > > > >> > >> > > > > execution if inspections detect a problem?
> > > > > > > > > >> > >> > > > >
> > > > > > > > > >> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay
> Izhikov <
> > > > > > > > nizhikov@apache.org>:
> > > > > > > > > >> > >> > > > > >
> > > > > > > > > >> > >> > > > > > 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
> > > > > > > > prototype.
> > > > > > > > > >> > >> > > > > >
> > > > > > > > > >> > >> > > > > > 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?
> > > > > > > > > >> > >> > > > > >
> > > > > > > > > >> > >> > > > > >
> > > > > > > > > >> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин
> Иван <
> > > > > > > > vololo100@gmail.com>:
> > > > > > > > > >> > >> > > > > >
> > > > > > > > > >> > >> > > > > > > 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
> > > > > > > > outline 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
> > > > > > > > that message).
> > > > > > > > > >> > >> > > > > > >
> > > > > > > > > >> > >> > > > > > > We have a document defining code style
> which every
> > > > > > > > contributor should
> > > > > > > > > >> > >> > > > > > > follow [1]. And many points can be
> checked
> > > > > > > > automatically. Personally,
> > > > > > > > > >> > >> > > > > > > I do not see much need in writing good
> javadocs for
> > > > > > > > prototype. Why
> > > > > > > > > >> > >> > > > > > > should I stub it to be able run any
> build on TC?
> > > > > > > > > >> > >> > > > > > >
> > > > > > > > > >> > >> > > > > > > Also, we a have a review process which
> should be
> > > > > > > > applied to every
> > > > > > > > > >> > >> > > > > > > patch. Partially it is described in
> [2]. And due to
> > > > > > > > this process every
> > > > > > > > > >> > >> > > > > > > patch should not introduce new
> failures on TC. So,
> > > > > > > > the patch should
> > > > > > > > > >> > >> > > > > > > not be merged if inspections failed.
> > > > > > > > > >> > >> > > > > > >
> > > > > > > > > >> > >> > > > > > > P.S. Something more about prototypes
> and production
> > > > > > > > code. There is a
> > > > > > > > > >> > >> > > > > > > common bad practice in software
> engineering. It is
> > > > > > > > turning prototypes
> > > > > > > > > >> > >> > > > > > > into production code. Often it is much
> faster to
> > > > > > > > create a prototype by
> > > > > > > > > >> > >> > > > > > > price of violating some rules of
> writing "clean
> > > > > > > > code". And often
> > > > > > > > > >> > >> > > > > > > prototype after successful piloting is
> turned into
> > > > > > > > production code.
> > > > > > > > > >> > >> > > > > > > And it is very easy in practice to
> keep some pieces
> > > > > > > > of 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"
> > > > > > > > from the beginning.
> > > > > > > > > >> > >> > > > > > > So, only ideas are taken from the
> prototype and a
> > > > > > > > code is fully
> > > > > > > > > >> > >> > > > > > > rewritten.
> > > > > > > > > >> > >> > > > > > >
> > > > > > > > > >> > >> > > > > > > [1]
> > > > > > > > > >> > >> > > > >
> > > > > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > > > > > > >> > >> > > > > > > [2]
> > > > > > > > > >> > >> > > > >
> > > > > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > > > > > > >> > >> > > > > > >
> > > > > > > > > >> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim
> Muzafarov <
> > > > > > > > maxmuzaf@gmail.com>:
> > > > > > > > > >> > >> > > > > > > >
> > > > > > > > > >> > >> > > > > > > > Ivan,
> > > > > > > > > >> > >> > > > > > > >
> > > > > > > > > >> > >> > > > > > > > As the first implementation of this
> addition, I'd
> > > > > > > > prefer to make it
> > > > > > > > > >> > >> > > > > > > > working like _Licenses Headers_
> suite check. It
> > > > > > > > will fail when some
> > > > > > > > > >> > >> > > > > of
> > > > > > > > > >> > >> > > > > > > > the code style checks violated.
> Moreover, these
> > > > > > > > licenses header
> > > > > > > > > >> > >> > > > > checks
> > > > > > > > > >> > >> > > > > > > > can be included in the checkstyle
> plugin
> > > > > > > > configuration.
> > > > > > > > > >> > >> > > > > > > >
> > > > > > > > > >> > >> > > > > > > > In general, I'd prefer to have a
> compilation fail
> > > > > > > > error with code
> > > > > > > > > >> > >> > > > > > > > style checks and after we will get a
> stable
> > > > > > > > checkstyle suite I
> > > > > > > > > >> > >> > > > > propose
> > > > > > > > > >> > >> > > > > > > > to change it in a "compilation
> error" way. If we
> > > > > > > > are talking about
> > > > > > > > > >> > >> > > > > the
> > > > > > > > > >> > >> > > > > > > > coding style convenient for most of
> the community
> > > > > > > > members I see no
> > > > > > > > > >> > >> > > > > > > > difference with coding sketches or
> > > > > > > > production-ready branches equally.
> > > > > > > > > >> > >> > > > > > > > Indeed, no one will be against
> unused imports [or
> > > > > > > > spaces 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() == 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 <
> > > > > > > > nizhikov@apache.org>
> > > > > > > > > >> > >> > > > > > > wrote:
> > > > > > > > > >> > >> > > > > > > > >
> > > > > > > > > >> > >> > > > > > > > > Actually, I dont see anything
> wrong with failing
> > > > > > > > *compilation*
> > > > > > > > > >> > >> > > > > task.
> > > > > > > > > >> > >> > > > > > > > >
> > > > > > > > > >> > >> > > > > > > > > I think one should use project
> code style for
> > > > > > > > everyday 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?
> > > > > > > > > >> > >> > > > > > > > >
> > > > > > > > > >> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr
> Ivanov
> > > > > > > > mr.weider@gmail.com:
> > > > > > > > > >> > >> > > > > > > > >
> > > > > > > > > >> > >> > > > > > > > > > I guess that was about failing
> build
> > > > > > > > configuration with
> > > > > > > > > >> > >> > > > > Checkstype,
> > > > > > > > > >> > >> > > > > > > not
> > > > > > > > > >> > >> > > > > > > > > > compilation build itself.
> > > > > > > > > >> > >> > > > > > > > > >
> > > > > > > > > >> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03,
> Павлухин Иван <
> > > > > > > > vololo100@gmail.com>
> > > > > > > > > >> > >> > > > > > > wrote:
> > > > > > > > > >> > >> > > > > > > > > > >
> > > > > > > > > >> > >> > > > > > > > > > > Folks,
> > > > > > > > > >> > >> > > > > > > > > > >
> > > > > > > > > >> > >> > > > > > > > > > > Are you going to fail job
> compiling Ignite
> > > > > > > > sources [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
> > > > > > > > convenient to skip some
> > > > > > > > > >> > >> > > > > style
> > > > > > > > > >> > >> > > > > > > > > > > requirements for such sketches
> (e.g. well
> > > > > > > > formed javadocs).
> > > > > > > > > >> > >> > > > > > > > > > >
> > > > > > > > > >> > >> > > > > > > > > > > [1]
> > > > > > > > > >> > >> > > > > > > > > >
> > > > > > > > > >> > >> > > > > > >
> > > > > > > > > >> > >> > > > >
> > > > > > > >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > > > > > >> > >> > > > > > > > > > >
> > > > > > > > > >> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38,
> Nikolay
> > > > > > > > Izhikov <
> > > > > > > > > >> > >> > > > > nizhikov@apache.org
> > > > > > > > > >> > >> > > > > > > >:
> > > > > > > > > >> > >> > > > > > > > > > >>
> > > > > > > > > >> > >> > > > > > > > > > >> Petr, we should have 1
> configuration for
> > > > > > > > project, may be 1
> > > > > > > > > >> > >> > > > > > > configuration
> > > > > > > > > >> > >> > > > > > > > > > >> per programming language.
> > > > > > > > > >> > >> > > > > > > > > > >>
> > > > > > > > > >> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33
> Petr Ivanov
> > > > > > > > mr.weider@gmail.com:
> > > > > > > > > >> > >> > > > > > > > > > >>
> > > > > > > > > >> > >> > > > > > > > > > >>> I was asking about how many
> build
> > > > > > > > configuration is intended?
> > > > > > > > > >> > >> > > > > One
> > > > > > > > > >> > >> > > > > > > for
> > > > > > > > > >> > >> > > > > > > > > > all
> > > > > > > > > >> > >> > > > > > > > > > >>> and multiple per module?
> > > > > > > > > >> > >> > > > > > > > > > >>>
> > > > > > > > > >> > >> > > > > > > > > > >>> With IDEA inspections it was
> going to be
> > > > > > > > build 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
> > > > > > > > build task? And each
> > > > > > > > > >> > >> > > > > > > module
> > > > > > > > > >> > >> > > > > > > > > > builds
> > > > > > > > > >> > >> > > > > > > > > > >>>> when it required? If yes,
> then I propose
> > > > > > > > to create a task
> > > > > > > > > >> > >> > > > > like
> > > > > > > > > >> > >> > > > > > > > > > "Licence
> > > > > > > > > >> > >> > > > > > > > > > >>>> check" which will be run
> for every patch.
> > > > > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>> My point is that violation
> of codestyle
> > > > > > > > should be treated as
> > > > > > > > > >> > >> > > > > > > hard as
> > > > > > > > > >> > >> > > > > > > > > > >>>> compile error.
> > > > > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16
> Petr Ivanov
> > > > > > > > mr.weider@gmail.com
> > > > > > > > > >> > >> > > > > :
> > > > > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>> Is build configuration
> Inspections
> > > > > > > > [Core] meant to
> > > > > > > > > >> > >> > > > > transform
> > > > > > > > > >> > >> > > > > > > into
> > > > > > > > > >> > >> > > > > > > > > > single
> > > > > > > > > >> > >> > > > > > > > > > >>>>> all-modules check build
> configuration
> > > > > > > > (without module
> > > > > > > > > >> > >> > > > > > > subdivision)?
> > > > > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02,
> Nikolay
> > > > > > > > Izhikov <
> > > > > > > > > >> > >> > > > > > > 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/1065-checkstyle-idea
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>> I propose do the
> following:
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>> 1. Migrate current checks
> to checkstyle.
> > > > > > > > > >> > >> > > > > > > > > > >>>>>> 2. Apply checks to all
> Ignite modules.
> > > > > > > > Currently, 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
> > > > > > > > Apache Ignite"
> > > > > > > > > >> > >> > > > > suite.
> > > > > > > > > >> > >> > > > > > > Ignite
> > > > > > > > > >> > >> > > > > > > > > > has
> > > > > > > > > >> > >> > > > > > > > > > >>>>> to
> > > > > > > > > >> > >> > > > > > > > > > >>>>>> fail to build if patch
> violates
> > > > > > > > codestyle.
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в
> 07:54, Павлухин
> > > > > > > > Иван <
> > > > > > > > > >> > >> > > > > > > vololo100@gmail.com>:
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>> Hi,
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>> I also think that some
> warning from
> > > > > > > > IDEA that some code
> > > > > > > > > >> > >> > > > > > > style rule
> > > > > > > > > >> > >> > > > > > > > > > is
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>> violated is a must-have.
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в
> 01:58,
> > > > > > > > oignatenko <
> > > > > > > > > >> > >> > > > > > > oignatenko@gridgain.com
> > > > > > > > > >> > >> > > > > > > > > > >:
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> I believe that whatever
> style checks
> > > > > > > > we establish at
> > > > > > > > > >> > >> > > > > > > Teamcity, we
> > > > > > > > > >> > >> > > > > > > > > > >>>>> better
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> take care of making it
> easy for
> > > > > > > > developers to find and
> > > > > > > > > >> > >> > > > > fix
> > > > > > > > > >> > >> > > > > > > > > > violations
> > > > > > > > > >> > >> > > > > > > > > > >>>>> in
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> their typical dev
> environment (for
> > > > > > > > Ignite this means, in
> > > > > > > > > >> > >> > > > > > > IDEA). I
> > > > > > > > > >> > >> > > > > > > > > > >>> think
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>> it
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> is important that
> developers can
> > > > > > > > maintain 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
> > > > > > > > just 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
> > > > > > > > checkstyle - I
> > > > > > > > > >> > >> > > > > recommend
> > > > > > > > > >> > >> > > > > > > keeping
> > > > > > > > > >> > >> > > > > > > > > > >>> its
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> config file somewhere
> in the project
> > > > > > > > under version
> > > > > > > > > >> > >> > > > > control.
> > > > > > > > > >> > >> > > > > > > I
> > > > > > > > > >> > >> > > > > > > > > > used to
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> maintain such a shared
> style config
> > > > > > > > at one of past jobs
> > > > > > > > > >> > >> > > > > and
> > > > > > > > > >> > >> > > > > > > after
> > > > > > > > > >> > >> > > > > > > > > > >>> some
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> experimenting it turned
> out most
> > > > > > > > convenient to have it
> > > > > > > > > >> > >> > > > > this
> > > > > > > > > >> > >> > > > > > > way -
> > > > > > > > > >> > >> > > > > > > > > > so
> > > > > > > > > >> > >> > > > > > > > > > >>>>> that
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> developers could easily
> assess and
> > > > > > > > discuss style
> > > > > > > > > >> > >> > > > > settings
> > > > > > > > > >> > >> > > > > > > and keep
> > > > > > > > > >> > >> > > > > > > > > > >>>>> track
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>> of
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>> changes in these. (note
> how Kafka
> > > > > > > > folks 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
> > > > > > > > community members.
> > > > > > > > > >> > >> > > > > > > Moreover, this
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> suite is no longer
> checks rules we
> > > > > > > > previously
> > > > > > > > > >> > >> > > > > 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
> > > > > > > > consider the Apache Kafka
> > > > > > > > > >> > >> > > > > > > code
> > > > > > > > > >> > >> > > > > > > > > > style
> > > > > > > > > >> > >> > > > > > > > > > >>> [5]
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> way and configure for
> the Ignite
> > > > > > > > project a
> > > > > > > > > >> > >> > > > > > > > > > maven-checkstyle-plugin
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> with its own maven
> profile and run
> > > > > > > > it simultaneously
> > > > > > > > > >> > >> > > > > with
> > > > > > > > > >> > >> > > > > > > other
> > > > > > > > > >> > >> > > > > > > > > > TC.
> > > > > > > > > >> > >> > > > > > > > > > >>> We
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> can also enable the
> previously
> > > > > > > > configured inspection
> > > > > > > > > >> > >> > > > > > > rules, so no
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> coding style
> violations will be
> > > > > > > > missed.
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> I see some advantages
> of using a
> > > > > > > > maven plugin:
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way
> for code checks
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> - can be used with
> different CI and
> > > > > > > > build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [2]
> > > > > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [3]
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>
> > > > > > > > > >> > >> > > > > > > > > >
> > > > > > > > > >> > >> > > > > > >
> > > > > > > > > >> > >> > > > >
> > > > > > > >
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [4]
> > > > > > > > https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [5]
> > > > > > > > > >> > >> > > > >
> https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at
> 16:03, Petr
> > > > > > > > Ivanov &lt;
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug
> in latest
> > > > > > > > 2018.2 TeamCity
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>> [1]
> > > > > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at
> 11:31, Petr
> > > > > > > > Ivanov &lt;
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>> Investigating
> problem, stand by.
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at
> 19:41, Dmitriy
> > > > > > > > Pavlov &lt;
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> dpavlov@
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; 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
> > > > > > > > next 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best regards,
> > > > > > > > Ivan Pavlukhin
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Code inspection

[Vyacheslav Daradur <da...@gmail.com>]

Also, I excluded "IntelliJ IDEA Inspections" from RunAll and marked it
as "~[Excluded]".

On Tue, Apr 23, 2019 at 12:25 AM Vyacheslav Daradur <da...@gmail.com> wrote:
>
> Maxim, I merged your changes to master.
>
> 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.
>
> Please check that it works as expected once again and announce new
> requirements in a separate thread to avoid confusion of community.
>
> cc Petr, Pavel (JFYI)
>
> [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=buildTypeBranches
>
> On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> >
> > Maxim,
> >
> > I left some comments in Jira, let's resolve them and I'll assist you
> > with merge and TC configuring.
> >
> > On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com> wrote:
> > >
> > > Vyacheslav,
> > >
> > > Thank you for your interest in making Ignite coding style better.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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;
> > >
> > > On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <da...@gmail.com> wrote:
> > > >
> > > > Maxim,
> > > >
> > > > I looked through the PR and it looks good to me in general.
> > > >
> > > > The only question how it's planned to maintain check styles in 2
> > > > different configurations, for IDEA and check style plugin?
> > > >
> > > > On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <ma...@gmail.com> wrote:
> > > > >
> > > > > Igniters,
> > > > >
> > > > > 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).
> > > > >
> > > > > JIRA: IGNITE-11277 [1]
> > > > > PR: [3]
> > > > > Upsource: [4]
> > > > >
> > > > > How can take a look?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > [2] http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
> > > > > [3] https://github.com/apache/ignite/pull/6119
> > > > > [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
> > > > >
> > > > > On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org> wrote:
> > > > > >
> > > > > > Hi Igniters,
> > > > > >
> > > > > > I see that a new TeamCity is released: Version: 2018.2.3.
> > > > > >
> > > > > > Probably it could solve recently introduced problem related to:
> > > > > > Unexpected error during build messages processing in TeamCity;
> > > > > >
> > > > > > Peter I., could you please check?
> > > > > >
> > > > > > Sincerely,
> > > > > > Dmitriy Pavlov
> > > > > >
> > > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > > > > >
> > > > > > > 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
> > > > > > > today.
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > > > > > > >
> > > > > > > > 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.
> > > > > > > >
> > > > > > > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
> > > > > > > > >
> > > > > > > > > +1 to enable code style checks in compile time.
> > > > > > > > >
> > > > > > > > > We can add option to disable maven codestyle profile with some
> > > > > > > environment variable.
> > > > > > > > >
> > > > > > > > > Anyone who want violate common project rules in their local branch can
> > > > > > > set this variable and write some nasty code before push :)
> > > > > > > > >
> > > > > > > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
> > > > > > > > >>
> > > > > > > > >> 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
> > > > > > > build stage.
> > > > > > > > >> - increases a bit the build time procedure
> > > > > > > > >> - require additional operations to switch it off for prototyping
> > > > > > > branches
> > > > > > > > >>
> > > > > > > > >> + do not require TC.Bot visa if someone of the community doesn't use
> > > > > > > it
> > > > > > > > >> + 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
> > > > > > > needs.
> > > > > > > > >>
> > > > > > > > >> ---
> > > > > > > > >>
> > > > > > > > >> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
> > > > > > > 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:
> > > > > > > > >> > ====Quoted text====
> > > > > > > > >> > 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.
> > > > > > > > >> > 2. Style check takes some time. With simple checks it is almost
> > > > > > > > >> > negligible. But it can grow if more checks are involved.
> > > > > > > > >> > ====End of quoted text====
> > > > > > > > >> >
> > > > > > > > >> > Some clarifications. 1 is about running from IDEA first. 2 is
> > > > > > > related
> > > > > > > > >> > to opinions that we should involve much more checks, e.g. using
> > > > > > > > >> > abbreviations.
> > > > > > > > >> >
> > > > > > > > >> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> > > > > > > > >> > >
> > > > > > > > >> > > Ivan,
> > > > > > > > >> > >
> > > > > > > > >> > > Let's take a look at all the options we have (ordered by the
> > > > > > > frequency 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
> > > > > > > checkstyle plugin is used in the <build> 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.
> > > > > > > > >> > >
> > > > > > > > >> > > Back to our use cases:
> > > > > > > > >> > >
> > > > > > > > >> > > 1. For checking the ready to merge branches we will fail the
> > > > > > > ~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.
> > > > > > > > >> > >
> > > > > > > > >> > > 2. For the prototyping branches, you can turn off checkstyle in
> > > > > > > your 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
> > > > > > > checkstyle enabled profile. The common build action as `mvn clean install
> > > > > > > -DskipTests` will activate the profile.
> > > > > > > > >> > >
> > > > > > > > >> > > 4. The checkstyle profile can be disabled explicitly on TC by
> > > > > > > specifying -P !checkstyle option. A don't see any use cases of it, but it's
> > > > > > > completely doable.
> > > > > > > > >> > >
> > > > > > > > >> > > Please, correct me if I've missed something.
> > > > > > > > >> > >
> > > > > > > > >> > > I propose to merge PR [1] as it is, with the configured set of
> > > > > > > rules.
> > > > > > > > >> > >
> > > > > > > > >> > > [1] https://github.com/apache/ignite/pull/6119
> > > > > > > > >> > >
> > > > > > > > >> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
> > > > > > > wrote:
> > > > > > > > >> > >>
> > > > > > > > >> > >> Maxim,
> > > > > > > > >> > >>
> > > > > > > > >> > >> I like an idea of being IDE agnostic. I am ok with currently
> > > > > > > enabled
> > > > > > > > >> > >> 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
> > > > > > > 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.
> > > > > > > > >> > >> 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"
> > > > > > > which I
> > > > > > > > >> > >> think is quite useful.
> > > > > > > > >> > >>
> > > > > > > > >> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
> > > > > > > >:
> > > > > > > > >> > >> >
> > > > > > > > >> > >> > Ivan,
> > > > > > > > >> > >> >
> > > > > > > > >> > >> > I like that Jetbrains inspections are integrated with IDE and
> > > > > > > TC 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
> > > > > > > with code
> > > > > > > > >> > >> > style checking. I've checked popular java projects: hadoop,
> > > > > > > kafka,
> > > > > > > > >> > >> > spark, hive, netty. All of them are using
> > > > > > > maven-checkstyle-plugin in
> > > > > > > > >> > >> > their <build> 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
> > > > > > > and
> > > > > > > > >> > >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose
> > > > > > > to 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-1018
> > > > > > > > >> > >> > [4]
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > > > > > > > >> > >> > [5] http://checkstyle.sourceforge.net/checks.html
> > > > > > > > >> > >> >
> > > > > > > > >> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> > > > > > > vololo100@gmail.com> 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
> > > > > > > checkstyle
> > > > > > > > >> > >> > > plugin? Is it integrated into IDEA out of box? As I got it
> > > > > > > additional
> > > > > > > > >> > >> > > 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
> > > > > > > visa. Visa
> > > > > > > > >> > >> > > includes result from running inspections job.
> > > > > > > > >> > >> > >
> > > > > > > > >> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> > > > > > > nizhikov@apache.org>:
> > > > > > > > >> > >> > > >
> > > > > > > > >> > >> > > > 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.
> > > > > > > > >> > >> > > >
> > > > > > > > >> > >> > > >
> > > > > > > > >> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> > > > > > > vololo100@gmail.com>:
> > > > > > > > >> > >> > > >
> > > > > > > > >> > >> > > > > Nikolay,
> > > > > > > > >> > >> > > > >
> > > > > > > > >> > >> > > > > > Should the community spend TC resources for  prototype?
> > > > > > > > >> > >> > > > > Why not? I think it is not bad idea to run all tests
> > > > > > > against 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
> > > > > > > with other
> > > > > > > > >> > >> > > > > Igniters. I think it is the cheapest way to check the
> > > > > > > idea because the
> > > > > > > > >> > >> > > > > check is fully automated. Requiring a human feedback is
> > > > > > > much 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
> > > > > > > skipping tests
> > > > > > > > >> > >> > > > > execution if inspections detect a problem?
> > > > > > > > >> > >> > > > >
> > > > > > > > >> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
> > > > > > > nizhikov@apache.org>:
> > > > > > > > >> > >> > > > > >
> > > > > > > > >> > >> > > > > > 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
> > > > > > > prototype.
> > > > > > > > >> > >> > > > > >
> > > > > > > > >> > >> > > > > > 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?
> > > > > > > > >> > >> > > > > >
> > > > > > > > >> > >> > > > > >
> > > > > > > > >> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
> > > > > > > vololo100@gmail.com>:
> > > > > > > > >> > >> > > > > >
> > > > > > > > >> > >> > > > > > > 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
> > > > > > > outline 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
> > > > > > > that message).
> > > > > > > > >> > >> > > > > > >
> > > > > > > > >> > >> > > > > > > We have a document defining code style which every
> > > > > > > contributor should
> > > > > > > > >> > >> > > > > > > follow [1]. And many points can be checked
> > > > > > > automatically. Personally,
> > > > > > > > >> > >> > > > > > > I do not see much need in writing good javadocs for
> > > > > > > prototype. Why
> > > > > > > > >> > >> > > > > > > should I stub it to be able run any build on TC?
> > > > > > > > >> > >> > > > > > >
> > > > > > > > >> > >> > > > > > > Also, we a have a review process which should be
> > > > > > > applied to every
> > > > > > > > >> > >> > > > > > > patch. Partially it is described in [2]. And due to
> > > > > > > this process every
> > > > > > > > >> > >> > > > > > > patch should not introduce new failures on TC. So,
> > > > > > > the patch should
> > > > > > > > >> > >> > > > > > > not be merged if inspections failed.
> > > > > > > > >> > >> > > > > > >
> > > > > > > > >> > >> > > > > > > P.S. Something more about prototypes and production
> > > > > > > code. There is a
> > > > > > > > >> > >> > > > > > > common bad practice in software engineering. It is
> > > > > > > turning prototypes
> > > > > > > > >> > >> > > > > > > into production code. Often it is much faster to
> > > > > > > create a prototype by
> > > > > > > > >> > >> > > > > > > price of violating some rules of writing "clean
> > > > > > > code". And often
> > > > > > > > >> > >> > > > > > > prototype after successful piloting is turned into
> > > > > > > production code.
> > > > > > > > >> > >> > > > > > > And it is very easy in practice to keep some pieces
> > > > > > > of 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"
> > > > > > > from the beginning.
> > > > > > > > >> > >> > > > > > > So, only ideas are taken from the prototype and a
> > > > > > > code is fully
> > > > > > > > >> > >> > > > > > > rewritten.
> > > > > > > > >> > >> > > > > > >
> > > > > > > > >> > >> > > > > > > [1]
> > > > > > > > >> > >> > > > >
> > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > > > > > >> > >> > > > > > > [2]
> > > > > > > > >> > >> > > > >
> > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > > > > > >> > >> > > > > > >
> > > > > > > > >> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
> > > > > > > maxmuzaf@gmail.com>:
> > > > > > > > >> > >> > > > > > > >
> > > > > > > > >> > >> > > > > > > > Ivan,
> > > > > > > > >> > >> > > > > > > >
> > > > > > > > >> > >> > > > > > > > As the first implementation of this addition, I'd
> > > > > > > prefer to make it
> > > > > > > > >> > >> > > > > > > > working like _Licenses Headers_ suite check. It
> > > > > > > will fail when some
> > > > > > > > >> > >> > > > > of
> > > > > > > > >> > >> > > > > > > > the code style checks violated. Moreover, these
> > > > > > > licenses header
> > > > > > > > >> > >> > > > > checks
> > > > > > > > >> > >> > > > > > > > can be included in the checkstyle plugin
> > > > > > > configuration.
> > > > > > > > >> > >> > > > > > > >
> > > > > > > > >> > >> > > > > > > > In general, I'd prefer to have a compilation fail
> > > > > > > error with code
> > > > > > > > >> > >> > > > > > > > style checks and after we will get a stable
> > > > > > > checkstyle suite I
> > > > > > > > >> > >> > > > > propose
> > > > > > > > >> > >> > > > > > > > to change it in a "compilation error" way. If we
> > > > > > > are talking about
> > > > > > > > >> > >> > > > > the
> > > > > > > > >> > >> > > > > > > > coding style convenient for most of the community
> > > > > > > members I see no
> > > > > > > > >> > >> > > > > > > > difference with coding sketches or
> > > > > > > production-ready branches equally.
> > > > > > > > >> > >> > > > > > > > Indeed, no one will be against unused imports [or
> > > > > > > spaces 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() == 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 <
> > > > > > > nizhikov@apache.org>
> > > > > > > > >> > >> > > > > > > wrote:
> > > > > > > > >> > >> > > > > > > > >
> > > > > > > > >> > >> > > > > > > > > Actually, I dont see anything wrong with failing
> > > > > > > *compilation*
> > > > > > > > >> > >> > > > > task.
> > > > > > > > >> > >> > > > > > > > >
> > > > > > > > >> > >> > > > > > > > > I think one should use project code style for
> > > > > > > everyday 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?
> > > > > > > > >> > >> > > > > > > > >
> > > > > > > > >> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov
> > > > > > > mr.weider@gmail.com:
> > > > > > > > >> > >> > > > > > > > >
> > > > > > > > >> > >> > > > > > > > > > I guess that was about failing build
> > > > > > > configuration with
> > > > > > > > >> > >> > > > > Checkstype,
> > > > > > > > >> > >> > > > > > > not
> > > > > > > > >> > >> > > > > > > > > > compilation build itself.
> > > > > > > > >> > >> > > > > > > > > >
> > > > > > > > >> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <
> > > > > > > vololo100@gmail.com>
> > > > > > > > >> > >> > > > > > > wrote:
> > > > > > > > >> > >> > > > > > > > > > >
> > > > > > > > >> > >> > > > > > > > > > > Folks,
> > > > > > > > >> > >> > > > > > > > > > >
> > > > > > > > >> > >> > > > > > > > > > > Are you going to fail job compiling Ignite
> > > > > > > sources [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
> > > > > > > convenient to skip some
> > > > > > > > >> > >> > > > > style
> > > > > > > > >> > >> > > > > > > > > > > requirements for such sketches (e.g. well
> > > > > > > formed javadocs).
> > > > > > > > >> > >> > > > > > > > > > >
> > > > > > > > >> > >> > > > > > > > > > > [1]
> > > > > > > > >> > >> > > > > > > > > >
> > > > > > > > >> > >> > > > > > >
> > > > > > > > >> > >> > > > >
> > > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > > > > >> > >> > > > > > > > > > >
> > > > > > > > >> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay
> > > > > > > Izhikov <
> > > > > > > > >> > >> > > > > nizhikov@apache.org
> > > > > > > > >> > >> > > > > > > >:
> > > > > > > > >> > >> > > > > > > > > > >>
> > > > > > > > >> > >> > > > > > > > > > >> Petr, we should have 1 configuration for
> > > > > > > project, may be 1
> > > > > > > > >> > >> > > > > > > configuration
> > > > > > > > >> > >> > > > > > > > > > >> per programming language.
> > > > > > > > >> > >> > > > > > > > > > >>
> > > > > > > > >> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
> > > > > > > mr.weider@gmail.com:
> > > > > > > > >> > >> > > > > > > > > > >>
> > > > > > > > >> > >> > > > > > > > > > >>> I was asking about how many build
> > > > > > > configuration is intended?
> > > > > > > > >> > >> > > > > One
> > > > > > > > >> > >> > > > > > > for
> > > > > > > > >> > >> > > > > > > > > > all
> > > > > > > > >> > >> > > > > > > > > > >>> and multiple per module?
> > > > > > > > >> > >> > > > > > > > > > >>>
> > > > > > > > >> > >> > > > > > > > > > >>> With IDEA inspections it was going to be
> > > > > > > build 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
> > > > > > > build task? And each
> > > > > > > > >> > >> > > > > > > module
> > > > > > > > >> > >> > > > > > > > > > builds
> > > > > > > > >> > >> > > > > > > > > > >>>> when it required? If yes, then I propose
> > > > > > > to create a task
> > > > > > > > >> > >> > > > > like
> > > > > > > > >> > >> > > > > > > > > > "Licence
> > > > > > > > >> > >> > > > > > > > > > >>>> check" which will be run for every patch.
> > > > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > > > >> > >> > > > > > > > > > >>>> My point is that violation of codestyle
> > > > > > > should be treated as
> > > > > > > > >> > >> > > > > > > hard as
> > > > > > > > >> > >> > > > > > > > > > >>>> compile error.
> > > > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > > > >> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
> > > > > > > mr.weider@gmail.com
> > > > > > > > >> > >> > > > > :
> > > > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>> Is build configuration Inspections
> > > > > > > [Core] meant to
> > > > > > > > >> > >> > > > > transform
> > > > > > > > >> > >> > > > > > > into
> > > > > > > > >> > >> > > > > > > > > > single
> > > > > > > > >> > >> > > > > > > > > > >>>>> all-modules check build configuration
> > > > > > > (without module
> > > > > > > > >> > >> > > > > > > subdivision)?
> > > > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay
> > > > > > > Izhikov <
> > > > > > > > >> > >> > > > > > > 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/1065-checkstyle-idea
> > > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>> I propose do the following:
> > > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > > > > > > >> > >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules.
> > > > > > > Currently, 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
> > > > > > > Apache Ignite"
> > > > > > > > >> > >> > > > > suite.
> > > > > > > > >> > >> > > > > > > Ignite
> > > > > > > > >> > >> > > > > > > > > > has
> > > > > > > > >> > >> > > > > > > > > > >>>>> to
> > > > > > > > >> > >> > > > > > > > > > >>>>>> fail to build if patch violates
> > > > > > > codestyle.
> > > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин
> > > > > > > Иван <
> > > > > > > > >> > >> > > > > > > vololo100@gmail.com>:
> > > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>> Hi,
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>> I also think that some warning from
> > > > > > > IDEA that some code
> > > > > > > > >> > >> > > > > > > style rule
> > > > > > > > >> > >> > > > > > > > > > is
> > > > > > > > >> > >> > > > > > > > > > >>>>>>> violated is a must-have.
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58,
> > > > > > > oignatenko <
> > > > > > > > >> > >> > > > > > > oignatenko@gridgain.com
> > > > > > > > >> > >> > > > > > > > > > >:
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>> I believe that whatever style checks
> > > > > > > we establish at
> > > > > > > > >> > >> > > > > > > Teamcity, we
> > > > > > > > >> > >> > > > > > > > > > >>>>> better
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>> take care of making it easy for
> > > > > > > developers to find and
> > > > > > > > >> > >> > > > > fix
> > > > > > > > >> > >> > > > > > > > > > violations
> > > > > > > > >> > >> > > > > > > > > > >>>>> in
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>> their typical dev environment (for
> > > > > > > Ignite this means, in
> > > > > > > > >> > >> > > > > > > IDEA). I
> > > > > > > > >> > >> > > > > > > > > > >>> think
> > > > > > > > >> > >> > > > > > > > > > >>>>>>> it
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>> is important that developers can
> > > > > > > maintain 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
> > > > > > > just 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
> > > > > > > checkstyle - I
> > > > > > > > >> > >> > > > > recommend
> > > > > > > > >> > >> > > > > > > keeping
> > > > > > > > >> > >> > > > > > > > > > >>> its
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>> config file somewhere in the project
> > > > > > > under version
> > > > > > > > >> > >> > > > > control.
> > > > > > > > >> > >> > > > > > > I
> > > > > > > > >> > >> > > > > > > > > > used to
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>> maintain such a shared style config
> > > > > > > at one of past jobs
> > > > > > > > >> > >> > > > > and
> > > > > > > > >> > >> > > > > > > after
> > > > > > > > >> > >> > > > > > > > > > >>> some
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>> experimenting it turned out most
> > > > > > > convenient to have it
> > > > > > > > >> > >> > > > > this
> > > > > > > > >> > >> > > > > > > way -
> > > > > > > > >> > >> > > > > > > > > > so
> > > > > > > > >> > >> > > > > > > > > > >>>>> that
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>> developers could easily assess and
> > > > > > > discuss style
> > > > > > > > >> > >> > > > > settings
> > > > > > > > >> > >> > > > > > > and keep
> > > > > > > > >> > >> > > > > > > > > > >>>>> track
> > > > > > > > >> > >> > > > > > > > > > >>>>>>> of
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka
> > > > > > > folks 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
> > > > > > > community members.
> > > > > > > > >> > >> > > > > > > Moreover, this
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we
> > > > > > > previously
> > > > > > > > >> > >> > > > > 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
> > > > > > > consider the Apache Kafka
> > > > > > > > >> > >> > > > > > > code
> > > > > > > > >> > >> > > > > > > > > > style
> > > > > > > > >> > >> > > > > > > > > > >>> [5]
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite
> > > > > > > project a
> > > > > > > > >> > >> > > > > > > > > > maven-checkstyle-plugin
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> with its own maven profile and run
> > > > > > > it simultaneously
> > > > > > > > >> > >> > > > > with
> > > > > > > > >> > >> > > > > > > other
> > > > > > > > >> > >> > > > > > > > > > TC.
> > > > > > > > >> > >> > > > > > > > > > >>> We
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> can also enable the previously
> > > > > > > configured inspection
> > > > > > > > >> > >> > > > > > > rules, so no
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> coding style violations will be
> > > > > > > missed.
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> I see some advantages of using a
> > > > > > > maven plugin:
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> - can be used with different CI and
> > > > > > > build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [2]
> > > > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [3]
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>
> > > > > > > > >> > >> > > > > > > > > >
> > > > > > > > >> > >> > > > > > >
> > > > > > > > >> > >> > > > >
> > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [4]
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [5]
> > > > > > > > >> > >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr
> > > > > > > Ivanov &lt;
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest
> > > > > > > 2018.2 TeamCity
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>> [1]
> > > > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr
> > > > > > > Ivanov &lt;
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy
> > > > > > > Pavlov &lt;
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> dpavlov@
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; 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
> > > > > > > next 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Ivan Pavlukhin
> > > > > > >
> > > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
>
>
>
> --
> Best Regards, Vyacheslav D.



-- 
Best Regards, Vyacheslav D.

Re: Code inspection

[Nikolay Izhikov <ni...@apache.org>]

Hello, Petr.

The main issue here is - we, as a community, still think that issue with code style is "minor".
Personally, I think there is no "minor" issues with code style - we should force single code style as hard as we can.

I think we *must* fail entire build if there are code style issues.

В Вт, 23/04/2019 в 13:03 +0300, Vyacheslav Daradur пишет:
> > > Also I still strictly against adding checkstyle to project build as minor issues in checkstyle should not be blocker for test run.
> 
> Me too.
> 
> Looks like everything works fine. Thanks! The only problem is long
> time of build ~10 minutes, because of dependencies resolving.
> 
> Maxim, please double check it.
> 
> On Tue, Apr 23, 2019 at 12:26 PM Petr Ivanov <mr...@gmail.com> wrote:
> > 
> > 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=3678000&buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=artifacts&branch_IgniteTests24Java8=%3Cdefault%3E#
> > 
> > 
> > > On 23 Apr 2019, at 11:59, Petr Ivanov <mr...@gmail.com> wrote:
> > > 
> > > I'll check it.
> > > 
> > > 
> > > Also, please pass TC build for review next time and do not add to Run All without it.
> > > 
> > > Thanks!
> > > 
> > > 
> > > > On 23 Apr 2019, at 11:53, Vyacheslav Daradur <da...@gmail.com> wrote:
> > > > 
> > > > This is quite strange error, in case of "install" phase it'd be better
> > > > just add "checkstyle" profile to "Build" [1] configuration.
> > > > 
> > > > [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > 
> > > > On Tue, Apr 23, 2019 at 11:43 AM Petr Ivanov <mr...@gmail.com> wrote:
> > > > > 
> > > > > The suite is malformed.
> > > > > If no ~/.m2/repository/org/apache/ignite artifact are installed in system, the build will fail [1]
> > > > > 
> > > > > It seems that we should use install instead of validate.
> > > > > 
> > > > > 
> > > > > [1] https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=3677858&_focus=288
> > > > > 
> > > > > 
> > > > > On 23 Apr 2019, at 00:25, Vyacheslav Daradur <da...@gmail.com> wrote:
> > > > > 
> > > > > Maxim, I merged your changes to master.
> > > > > 
> > > > > 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.
> > > > > 
> > > > > Please check that it works as expected once again and announce new
> > > > > requirements in a separate thread to avoid confusion of community.
> > > > > 
> > > > > cc Petr, Pavel (JFYI)
> > > > > 
> > > > > [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=buildTypeBranches
> > > > > 
> > > > > On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> > > > > 
> > > > > 
> > > > > Maxim,
> > > > > 
> > > > > I left some comments in Jira, let's resolve them and I'll assist you
> > > > > with merge and TC configuring.
> > > > > 
> > > > > On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com> wrote:
> > > > > 
> > > > > 
> > > > > Vyacheslav,
> > > > > 
> > > > > Thank you for your interest in making Ignite coding style better.
> > > > > 
> > > > > 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.
> > > > > 
> > > > > 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.
> > > > > 
> > > > > 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;
> > > > > 
> > > > > On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <da...@gmail.com> wrote:
> > > > > 
> > > > > 
> > > > > Maxim,
> > > > > 
> > > > > I looked through the PR and it looks good to me in general.
> > > > > 
> > > > > The only question how it's planned to maintain check styles in 2
> > > > > different configurations, for IDEA and check style plugin?
> > > > > 
> > > > > On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <ma...@gmail.com> wrote:
> > > > > 
> > > > > 
> > > > > Igniters,
> > > > > 
> > > > > 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).
> > > > > 
> > > > > JIRA: IGNITE-11277 [1]
> > > > > PR: [3]
> > > > > Upsource: [4]
> > > > > 
> > > > > How can take a look?
> > > > > 
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > [2] http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
> > > > > [3] https://github.com/apache/ignite/pull/6119
> > > > > [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
> > > > > 
> > > > > On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org> wrote:
> > > > > 
> > > > > 
> > > > > Hi Igniters,
> > > > > 
> > > > > I see that a new TeamCity is released: Version: 2018.2.3.
> > > > > 
> > > > > Probably it could solve recently introduced problem related to:
> > > > > Unexpected error during build messages processing in TeamCity;
> > > > > 
> > > > > Peter I., could you please check?
> > > > > 
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > > 
> > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > > > > 
> > > > > 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
> > > > > today.
> > > > > 
> > > > > 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.
> > > > > 
> > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > > > > 
> > > > > 
> > > > > 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.
> > > > > 
> > > > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
> > > > > 
> > > > > 
> > > > > +1 to enable code style checks in compile time.
> > > > > 
> > > > > We can add option to disable maven codestyle profile with some
> > > > > 
> > > > > environment variable.
> > > > > 
> > > > > 
> > > > > Anyone who want violate common project rules in their local branch can
> > > > > 
> > > > > set this variable and write some nasty code before push :)
> > > > > 
> > > > > 
> > > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
> > > > > 
> > > > > 
> > > > > 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
> > > > > 
> > > > > build stage.
> > > > > 
> > > > > - increases a bit the build time procedure
> > > > > - require additional operations to switch it off for prototyping
> > > > > 
> > > > > branches
> > > > > 
> > > > > 
> > > > > + do not require TC.Bot visa if someone of the community doesn't use
> > > > > 
> > > > > it
> > > > > 
> > > > > + 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
> > > > > 
> > > > > needs.
> > > > > 
> > > > > 
> > > > > ---
> > > > > 
> > > > > 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
> > > > > 
> > > > > 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:
> > > > > ====Quoted text====
> > > > > 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.
> > > > > 2. Style check takes some time. With simple checks it is almost
> > > > > negligible. But it can grow if more checks are involved.
> > > > > ====End of quoted text====
> > > > > 
> > > > > Some clarifications. 1 is about running from IDEA first. 2 is
> > > > > 
> > > > > related
> > > > > 
> > > > > to opinions that we should involve much more checks, e.g. using
> > > > > abbreviations.
> > > > > 
> > > > > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> > > > > 
> > > > > 
> > > > > Ivan,
> > > > > 
> > > > > Let's take a look at all the options we have (ordered by the
> > > > > 
> > > > > frequency 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
> > > > > 
> > > > > checkstyle plugin is used in the <build> 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.
> > > > > 
> > > > > 
> > > > > Back to our use cases:
> > > > > 
> > > > > 1. For checking the ready to merge branches we will fail the
> > > > > 
> > > > > ~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.
> > > > > 
> > > > > 
> > > > > 2. For the prototyping branches, you can turn off checkstyle in
> > > > > 
> > > > > your 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
> > > > > 
> > > > > checkstyle enabled profile. The common build action as `mvn clean install
> > > > > -DskipTests` will activate the profile.
> > > > > 
> > > > > 
> > > > > 4. The checkstyle profile can be disabled explicitly on TC by
> > > > > 
> > > > > specifying -P !checkstyle option. A don't see any use cases of it, but it's
> > > > > completely doable.
> > > > > 
> > > > > 
> > > > > Please, correct me if I've missed something.
> > > > > 
> > > > > I propose to merge PR [1] as it is, with the configured set of
> > > > > 
> > > > > rules.
> > > > > 
> > > > > 
> > > > > [1] https://github.com/apache/ignite/pull/6119
> > > > > 
> > > > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
> > > > > 
> > > > > wrote:
> > > > > 
> > > > > 
> > > > > Maxim,
> > > > > 
> > > > > I like an idea of being IDE agnostic. I am ok with currently
> > > > > 
> > > > > enabled
> > > > > 
> > > > > 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
> > > > > 
> > > > > 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.
> > > > > 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"
> > > > > 
> > > > > which I
> > > > > 
> > > > > think is quite useful.
> > > > > 
> > > > > пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
> > > > > 
> > > > > :
> > > > > 
> > > > > 
> > > > > Ivan,
> > > > > 
> > > > > I like that Jetbrains inspections are integrated with IDE and
> > > > > 
> > > > > TC 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
> > > > > 
> > > > > with code
> > > > > 
> > > > > style checking. I've checked popular java projects: hadoop,
> > > > > 
> > > > > kafka,
> > > > > 
> > > > > spark, hive, netty. All of them are using
> > > > > 
> > > > > maven-checkstyle-plugin in
> > > > > 
> > > > > their <build> 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
> > > > > 
> > > > > and
> > > > > 
> > > > > SizeReplaceableByIsEmpty (all code style checks [5]). Propose
> > > > > 
> > > > > to 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-1018
> > > > > 
> > > > > [4]
> > > > > 
> > > > > https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > > > > 
> > > > > [5] http://checkstyle.sourceforge.net/checks.html
> > > > > 
> > > > > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> > > > > 
> > > > > vololo100@gmail.com> 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
> > > > > 
> > > > > checkstyle
> > > > > 
> > > > > plugin? Is it integrated into IDEA out of box? As I got it
> > > > > 
> > > > > additional
> > > > > 
> > > > > 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
> > > > > 
> > > > > visa. Visa
> > > > > 
> > > > > includes result from running inspections job.
> > > > > 
> > > > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> > > > > 
> > > > > nizhikov@apache.org>:
> > > > > 
> > > > > 
> > > > > 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.
> > > > > 
> > > > > 
> > > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> > > > > 
> > > > > vololo100@gmail.com>:
> > > > > 
> > > > > 
> > > > > Nikolay,
> > > > > 
> > > > > Should the community spend TC resources for  prototype?
> > > > > 
> > > > > Why not? I think it is not bad idea to run all tests
> > > > > 
> > > > > against 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
> > > > > 
> > > > > with other
> > > > > 
> > > > > Igniters. I think it is the cheapest way to check the
> > > > > 
> > > > > idea because the
> > > > > 
> > > > > check is fully automated. Requiring a human feedback is
> > > > > 
> > > > > much 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
> > > > > 
> > > > > skipping tests
> > > > > 
> > > > > execution if inspections detect a problem?
> > > > > 
> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
> > > > > 
> > > > > nizhikov@apache.org>:
> > > > > 
> > > > > 
> > > > > 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
> > > > > 
> > > > > prototype.
> > > > > 
> > > > > 
> > > > > 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?
> > > > > 
> > > > > 
> > > > > 
> > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
> > > > > 
> > > > > vololo100@gmail.com>:
> > > > > 
> > > > > 
> > > > > 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
> > > > > 
> > > > > outline 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
> > > > > 
> > > > > that message).
> > > > > 
> > > > > 
> > > > > We have a document defining code style which every
> > > > > 
> > > > > contributor should
> > > > > 
> > > > > follow [1]. And many points can be checked
> > > > > 
> > > > > automatically. Personally,
> > > > > 
> > > > > I do not see much need in writing good javadocs for
> > > > > 
> > > > > prototype. Why
> > > > > 
> > > > > should I stub it to be able run any build on TC?
> > > > > 
> > > > > Also, we a have a review process which should be
> > > > > 
> > > > > applied to every
> > > > > 
> > > > > patch. Partially it is described in [2]. And due to
> > > > > 
> > > > > this process every
> > > > > 
> > > > > patch should not introduce new failures on TC. So,
> > > > > 
> > > > > the patch should
> > > > > 
> > > > > not be merged if inspections failed.
> > > > > 
> > > > > P.S. Something more about prototypes and production
> > > > > 
> > > > > code. There is a
> > > > > 
> > > > > common bad practice in software engineering. It is
> > > > > 
> > > > > turning prototypes
> > > > > 
> > > > > into production code. Often it is much faster to
> > > > > 
> > > > > create a prototype by
> > > > > 
> > > > > price of violating some rules of writing "clean
> > > > > 
> > > > > code". And often
> > > > > 
> > > > > prototype after successful piloting is turned into
> > > > > 
> > > > > production code.
> > > > > 
> > > > > And it is very easy in practice to keep some pieces
> > > > > 
> > > > > of 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"
> > > > > 
> > > > > from the beginning.
> > > > > 
> > > > > So, only ideas are taken from the prototype and a
> > > > > 
> > > > > code is fully
> > > > > 
> > > > > rewritten.
> > > > > 
> > > > > [1]
> > > > > 
> > > > > 
> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > > 
> > > > > [2]
> > > > > 
> > > > > 
> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > > 
> > > > > 
> > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
> > > > > 
> > > > > maxmuzaf@gmail.com>:
> > > > > 
> > > > > 
> > > > > Ivan,
> > > > > 
> > > > > As the first implementation of this addition, I'd
> > > > > 
> > > > > prefer to make it
> > > > > 
> > > > > working like _Licenses Headers_ suite check. It
> > > > > 
> > > > > will fail when some
> > > > > 
> > > > > of
> > > > > 
> > > > > the code style checks violated. Moreover, these
> > > > > 
> > > > > licenses header
> > > > > 
> > > > > checks
> > > > > 
> > > > > can be included in the checkstyle plugin
> > > > > 
> > > > > configuration.
> > > > > 
> > > > > 
> > > > > In general, I'd prefer to have a compilation fail
> > > > > 
> > > > > error with code
> > > > > 
> > > > > style checks and after we will get a stable
> > > > > 
> > > > > checkstyle suite I
> > > > > 
> > > > > propose
> > > > > 
> > > > > to change it in a "compilation error" way. If we
> > > > > 
> > > > > are talking about
> > > > > 
> > > > > the
> > > > > 
> > > > > coding style convenient for most of the community
> > > > > 
> > > > > members I see no
> > > > > 
> > > > > difference with coding sketches or
> > > > > 
> > > > > production-ready branches equally.
> > > > > 
> > > > > Indeed, no one will be against unused imports [or
> > > > > 
> > > > > spaces 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() == 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 <
> > > > > 
> > > > > nizhikov@apache.org>
> > > > > 
> > > > > wrote:
> > > > > 
> > > > > 
> > > > > Actually, I dont see anything wrong with failing
> > > > > 
> > > > > *compilation*
> > > > > 
> > > > > task.
> > > > > 
> > > > > 
> > > > > I think one should use project code style for
> > > > > 
> > > > > everyday 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?
> > > > > 
> > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov
> > > > > 
> > > > > mr.weider@gmail.com:
> > > > > 
> > > > > 
> > > > > I guess that was about failing build
> > > > > 
> > > > > configuration with
> > > > > 
> > > > > Checkstype,
> > > > > 
> > > > > not
> > > > > 
> > > > > compilation build itself.
> > > > > 
> > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <
> > > > > 
> > > > > vololo100@gmail.com>
> > > > > 
> > > > > wrote:
> > > > > 
> > > > > 
> > > > > Folks,
> > > > > 
> > > > > Are you going to fail job compiling Ignite
> > > > > 
> > > > > sources [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
> > > > > 
> > > > > convenient to skip some
> > > > > 
> > > > > style
> > > > > 
> > > > > requirements for such sketches (e.g. well
> > > > > 
> > > > > formed javadocs).
> > > > > 
> > > > > 
> > > > > [1]
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > 
> > > > > 
> > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay
> > > > > 
> > > > > Izhikov <
> > > > > 
> > > > > nizhikov@apache.org
> > > > > 
> > > > > :
> > > > > 
> > > > > 
> > > > > Petr, we should have 1 configuration for
> > > > > 
> > > > > project, may be 1
> > > > > 
> > > > > configuration
> > > > > 
> > > > > per programming language.
> > > > > 
> > > > > пн, 11 февр. 2019 г., 11:33 Petr Ivanov
> > > > > 
> > > > > mr.weider@gmail.com:
> > > > > 
> > > > > 
> > > > > I was asking about how many build
> > > > > 
> > > > > configuration is intended?
> > > > > 
> > > > > One
> > > > > 
> > > > > for
> > > > > 
> > > > > all
> > > > > 
> > > > > and multiple per module?
> > > > > 
> > > > > With IDEA inspections it was going to be
> > > > > 
> > > > > build 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
> > > > > 
> > > > > build task? And each
> > > > > 
> > > > > module
> > > > > 
> > > > > builds
> > > > > 
> > > > > when it required? If yes, then I propose
> > > > > 
> > > > > to create a task
> > > > > 
> > > > > like
> > > > > 
> > > > > "Licence
> > > > > 
> > > > > check" which will be run for every patch.
> > > > > 
> > > > > My point is that violation of codestyle
> > > > > 
> > > > > should be treated as
> > > > > 
> > > > > hard as
> > > > > 
> > > > > compile error.
> > > > > 
> > > > > пн, 11 февр. 2019 г., 11:16 Petr Ivanov
> > > > > 
> > > > > mr.weider@gmail.com
> > > > > 
> > > > > :
> > > > > 
> > > > > 
> > > > > Is build configuration Inspections
> > > > > 
> > > > > [Core] meant to
> > > > > 
> > > > > transform
> > > > > 
> > > > > into
> > > > > 
> > > > > single
> > > > > 
> > > > > all-modules check build configuration
> > > > > 
> > > > > (without module
> > > > > 
> > > > > subdivision)?
> > > > > 
> > > > > 
> > > > > 
> > > > > On 11 Feb 2019, at 11:02, Nikolay
> > > > > 
> > > > > Izhikov <
> > > > > 
> > > > > 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/1065-checkstyle-idea
> > > > > 
> > > > > 
> > > > > I propose do the following:
> > > > > 
> > > > > 1. Migrate current checks to checkstyle.
> > > > > 2. Apply checks to all Ignite modules.
> > > > > 
> > > > > Currently, 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
> > > > > 
> > > > > Apache Ignite"
> > > > > 
> > > > > suite.
> > > > > 
> > > > > Ignite
> > > > > 
> > > > > has
> > > > > 
> > > > > to
> > > > > 
> > > > > fail to build if patch violates
> > > > > 
> > > > > codestyle.
> > > > > 
> > > > > 
> > > > > вс, 10 февр. 2019 г. в 07:54, Павлухин
> > > > > 
> > > > > Иван <
> > > > > 
> > > > > vololo100@gmail.com>:
> > > > > 
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I also think that some warning from
> > > > > 
> > > > > IDEA that some code
> > > > > 
> > > > > style rule
> > > > > 
> > > > > is
> > > > > 
> > > > > violated is a must-have.
> > > > > 
> > > > > вс, 10 февр. 2019 г. в 01:58,
> > > > > 
> > > > > oignatenko <
> > > > > 
> > > > > oignatenko@gridgain.com
> > > > > 
> > > > > :
> > > > > 
> > > > > 
> > > > > Hi Maxim,
> > > > > 
> > > > > I believe that whatever style checks
> > > > > 
> > > > > we establish at
> > > > > 
> > > > > Teamcity, we
> > > > > 
> > > > > better
> > > > > 
> > > > > take care of making it easy for
> > > > > 
> > > > > developers to find and
> > > > > 
> > > > > fix
> > > > > 
> > > > > violations
> > > > > 
> > > > > in
> > > > > 
> > > > > their typical dev environment (for
> > > > > 
> > > > > Ignite this means, in
> > > > > 
> > > > > IDEA). I
> > > > > 
> > > > > think
> > > > > 
> > > > > it
> > > > > 
> > > > > is important that developers can
> > > > > 
> > > > > maintain 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
> > > > > 
> > > > > just 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
> > > > > 
> > > > > checkstyle - I
> > > > > 
> > > > > recommend
> > > > > 
> > > > > keeping
> > > > > 
> > > > > its
> > > > > 
> > > > > config file somewhere in the project
> > > > > 
> > > > > under version
> > > > > 
> > > > > control.
> > > > > 
> > > > > I
> > > > > 
> > > > > used to
> > > > > 
> > > > > maintain such a shared style config
> > > > > 
> > > > > at one of past jobs
> > > > > 
> > > > > and
> > > > > 
> > > > > after
> > > > > 
> > > > > some
> > > > > 
> > > > > experimenting it turned out most
> > > > > 
> > > > > convenient to have it
> > > > > 
> > > > > this
> > > > > 
> > > > > way -
> > > > > 
> > > > > so
> > > > > 
> > > > > that
> > > > > 
> > > > > developers could easily assess and
> > > > > 
> > > > > discuss style
> > > > > 
> > > > > settings
> > > > > 
> > > > > and keep
> > > > > 
> > > > > track
> > > > > 
> > > > > of
> > > > > 
> > > > > changes in these. (note how Kafka
> > > > > 
> > > > > folks 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
> > > > > 
> > > > > community members.
> > > > > 
> > > > > Moreover, this
> > > > > 
> > > > > suite is no longer checks rules we
> > > > > 
> > > > > previously
> > > > > 
> > > > > 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
> > > > > 
> > > > > consider the Apache Kafka
> > > > > 
> > > > > code
> > > > > 
> > > > > style
> > > > > 
> > > > > [5]
> > > > > 
> > > > > way and configure for the Ignite
> > > > > 
> > > > > project a
> > > > > 
> > > > > maven-checkstyle-plugin
> > > > > 
> > > > > with its own maven profile and run
> > > > > 
> > > > > it simultaneously
> > > > > 
> > > > > with
> > > > > 
> > > > > other
> > > > > 
> > > > > TC.
> > > > > 
> > > > > We
> > > > > 
> > > > > can also enable the previously
> > > > > 
> > > > > configured inspection
> > > > > 
> > > > > rules, so no
> > > > > 
> > > > > coding style violations will be
> > > > > 
> > > > > missed.
> > > > > 
> > > > > 
> > > > > I see some advantages of using a
> > > > > 
> > > > > maven plugin:
> > > > > 
> > > > > - an IDE agnostic way for code checks
> > > > > - can be used with different CI and
> > > > > 
> > > > > build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > 
> > > > > [2]
> > > > > 
> > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > 
> > > > > [3]
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > 
> > > > > [4]
> > > > > 
> > > > > https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > 
> > > > > [5]
> > > > > 
> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > 
> > > > > 
> > > > > On Fri, 21 Dec 2018 at 16:03, Petr
> > > > > 
> > > > > Ivanov &lt;
> > > > > 
> > > > > 
> > > > > mr.weider@
> > > > > 
> > > > > 
> > > > > &gt; wrote:
> > > > > 
> > > > > 
> > > > > It seems there is bug in latest
> > > > > 
> > > > > 2018.2 TeamCity
> > > > > 
> > > > > Bug is filed [1]
> > > > > 
> > > > > 
> > > > > [1]
> > > > > 
> > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > 
> > > > > 
> > > > > On 19 Dec 2018, at 11:31, Petr
> > > > > 
> > > > > Ivanov &lt;
> > > > > 
> > > > > 
> > > > > mr.weider@
> > > > > 
> > > > > 
> > > > > &gt; wrote:
> > > > > 
> > > > > 
> > > > > Investigating problem, stand by.
> > > > > 
> > > > > 
> > > > > On 18 Dec 2018, at 19:41, Dmitriy
> > > > > 
> > > > > Pavlov &lt;
> > > > > 
> > > > > 
> > > > > dpavlov@
> > > > > 
> > > > > 
> > > > > &gt; 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
> > > > > 
> > > > > next 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
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > --
> > > > Best Regards, Vyacheslav D.
> 
> 

Re: Code inspection

[Vyacheslav Daradur <da...@gmail.com>]

>> Also I still strictly against adding checkstyle to project build as minor issues in checkstyle should not be blocker for test run.

Me too.

Looks like everything works fine. Thanks! The only problem is long
time of build ~10 minutes, because of dependencies resolving.

Maxim, please double check it.

On Tue, Apr 23, 2019 at 12:26 PM Petr Ivanov <mr...@gmail.com> wrote:
>
> 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=3678000&buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=artifacts&branch_IgniteTests24Java8=%3Cdefault%3E#
>
>
> > On 23 Apr 2019, at 11:59, Petr Ivanov <mr...@gmail.com> wrote:
> >
> > I'll check it.
> >
> >
> > Also, please pass TC build for review next time and do not add to Run All without it.
> >
> > Thanks!
> >
> >
> >> On 23 Apr 2019, at 11:53, Vyacheslav Daradur <da...@gmail.com> wrote:
> >>
> >> This is quite strange error, in case of "install" phase it'd be better
> >> just add "checkstyle" profile to "Build" [1] configuration.
> >>
> >> [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> >>
> >> On Tue, Apr 23, 2019 at 11:43 AM Petr Ivanov <mr...@gmail.com> wrote:
> >>>
> >>> The suite is malformed.
> >>> If no ~/.m2/repository/org/apache/ignite artifact are installed in system, the build will fail [1]
> >>>
> >>> It seems that we should use install instead of validate.
> >>>
> >>>
> >>> [1] https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=3677858&_focus=288
> >>>
> >>>
> >>> On 23 Apr 2019, at 00:25, Vyacheslav Daradur <da...@gmail.com> wrote:
> >>>
> >>> Maxim, I merged your changes to master.
> >>>
> >>> 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.
> >>>
> >>> Please check that it works as expected once again and announce new
> >>> requirements in a separate thread to avoid confusion of community.
> >>>
> >>> cc Petr, Pavel (JFYI)
> >>>
> >>> [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=buildTypeBranches
> >>>
> >>> On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> >>>
> >>>
> >>> Maxim,
> >>>
> >>> I left some comments in Jira, let's resolve them and I'll assist you
> >>> with merge and TC configuring.
> >>>
> >>> On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com> wrote:
> >>>
> >>>
> >>> Vyacheslav,
> >>>
> >>> Thank you for your interest in making Ignite coding style better.
> >>>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>> 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;
> >>>
> >>> On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <da...@gmail.com> wrote:
> >>>
> >>>
> >>> Maxim,
> >>>
> >>> I looked through the PR and it looks good to me in general.
> >>>
> >>> The only question how it's planned to maintain check styles in 2
> >>> different configurations, for IDEA and check style plugin?
> >>>
> >>> On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <ma...@gmail.com> wrote:
> >>>
> >>>
> >>> Igniters,
> >>>
> >>> 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).
> >>>
> >>> JIRA: IGNITE-11277 [1]
> >>> PR: [3]
> >>> Upsource: [4]
> >>>
> >>> How can take a look?
> >>>
> >>> [1] https://issues.apache.org/jira/browse/IGNITE-11277
> >>> [2] http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
> >>> [3] https://github.com/apache/ignite/pull/6119
> >>> [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
> >>>
> >>> On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org> wrote:
> >>>
> >>>
> >>> Hi Igniters,
> >>>
> >>> I see that a new TeamCity is released: Version: 2018.2.3.
> >>>
> >>> Probably it could solve recently introduced problem related to:
> >>> Unexpected error during build messages processing in TeamCity;
> >>>
> >>> Peter I., could you please check?
> >>>
> >>> Sincerely,
> >>> Dmitriy Pavlov
> >>>
> >>> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> >>>
> >>> 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
> >>> today.
> >>>
> >>> 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.
> >>>
> >>> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> >>>
> >>>
> >>> 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.
> >>>
> >>> пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
> >>>
> >>>
> >>> +1 to enable code style checks in compile time.
> >>>
> >>> We can add option to disable maven codestyle profile with some
> >>>
> >>> environment variable.
> >>>
> >>>
> >>> Anyone who want violate common project rules in their local branch can
> >>>
> >>> set this variable and write some nasty code before push :)
> >>>
> >>>
> >>> пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
> >>>
> >>>
> >>> 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
> >>>
> >>> build stage.
> >>>
> >>> - increases a bit the build time procedure
> >>> - require additional operations to switch it off for prototyping
> >>>
> >>> branches
> >>>
> >>>
> >>> + do not require TC.Bot visa if someone of the community doesn't use
> >>>
> >>> it
> >>>
> >>> + 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
> >>>
> >>> needs.
> >>>
> >>>
> >>> ---
> >>>
> >>> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
> >>>
> >>> 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:
> >>> ====Quoted text====
> >>> 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.
> >>> 2. Style check takes some time. With simple checks it is almost
> >>> negligible. But it can grow if more checks are involved.
> >>> ====End of quoted text====
> >>>
> >>> Some clarifications. 1 is about running from IDEA first. 2 is
> >>>
> >>> related
> >>>
> >>> to opinions that we should involve much more checks, e.g. using
> >>> abbreviations.
> >>>
> >>> чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> >>>
> >>>
> >>> Ivan,
> >>>
> >>> Let's take a look at all the options we have (ordered by the
> >>>
> >>> frequency 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
> >>>
> >>> checkstyle plugin is used in the <build> 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.
> >>>
> >>>
> >>> Back to our use cases:
> >>>
> >>> 1. For checking the ready to merge branches we will fail the
> >>>
> >>> ~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.
> >>>
> >>>
> >>> 2. For the prototyping branches, you can turn off checkstyle in
> >>>
> >>> your 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
> >>>
> >>> checkstyle enabled profile. The common build action as `mvn clean install
> >>> -DskipTests` will activate the profile.
> >>>
> >>>
> >>> 4. The checkstyle profile can be disabled explicitly on TC by
> >>>
> >>> specifying -P !checkstyle option. A don't see any use cases of it, but it's
> >>> completely doable.
> >>>
> >>>
> >>> Please, correct me if I've missed something.
> >>>
> >>> I propose to merge PR [1] as it is, with the configured set of
> >>>
> >>> rules.
> >>>
> >>>
> >>> [1] https://github.com/apache/ignite/pull/6119
> >>>
> >>> On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> Maxim,
> >>>
> >>> I like an idea of being IDE agnostic. I am ok with currently
> >>>
> >>> enabled
> >>>
> >>> 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
> >>>
> >>> 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.
> >>> 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"
> >>>
> >>> which I
> >>>
> >>> think is quite useful.
> >>>
> >>> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
> >>>
> >>> :
> >>>
> >>>
> >>> Ivan,
> >>>
> >>> I like that Jetbrains inspections are integrated with IDE and
> >>>
> >>> TC 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
> >>>
> >>> with code
> >>>
> >>> style checking. I've checked popular java projects: hadoop,
> >>>
> >>> kafka,
> >>>
> >>> spark, hive, netty. All of them are using
> >>>
> >>> maven-checkstyle-plugin in
> >>>
> >>> their <build> 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
> >>>
> >>> and
> >>>
> >>> SizeReplaceableByIsEmpty (all code style checks [5]). Propose
> >>>
> >>> to 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-1018
> >>>
> >>> [4]
> >>>
> >>> https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> >>>
> >>> [5] http://checkstyle.sourceforge.net/checks.html
> >>>
> >>> On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> >>>
> >>> vololo100@gmail.com> 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
> >>>
> >>> checkstyle
> >>>
> >>> plugin? Is it integrated into IDEA out of box? As I got it
> >>>
> >>> additional
> >>>
> >>> 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
> >>>
> >>> visa. Visa
> >>>
> >>> includes result from running inspections job.
> >>>
> >>> чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> >>>
> >>> nizhikov@apache.org>:
> >>>
> >>>
> >>> 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.
> >>>
> >>>
> >>> чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> >>>
> >>> vololo100@gmail.com>:
> >>>
> >>>
> >>> Nikolay,
> >>>
> >>> Should the community spend TC resources for  prototype?
> >>>
> >>> Why not? I think it is not bad idea to run all tests
> >>>
> >>> against 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
> >>>
> >>> with other
> >>>
> >>> Igniters. I think it is the cheapest way to check the
> >>>
> >>> idea because the
> >>>
> >>> check is fully automated. Requiring a human feedback is
> >>>
> >>> much 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
> >>>
> >>> skipping tests
> >>>
> >>> execution if inspections detect a problem?
> >>>
> >>> чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
> >>>
> >>> nizhikov@apache.org>:
> >>>
> >>>
> >>> 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
> >>>
> >>> prototype.
> >>>
> >>>
> >>> 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?
> >>>
> >>>
> >>>
> >>> ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
> >>>
> >>> vololo100@gmail.com>:
> >>>
> >>>
> >>> 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
> >>>
> >>> outline 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
> >>>
> >>> that message).
> >>>
> >>>
> >>> We have a document defining code style which every
> >>>
> >>> contributor should
> >>>
> >>> follow [1]. And many points can be checked
> >>>
> >>> automatically. Personally,
> >>>
> >>> I do not see much need in writing good javadocs for
> >>>
> >>> prototype. Why
> >>>
> >>> should I stub it to be able run any build on TC?
> >>>
> >>> Also, we a have a review process which should be
> >>>
> >>> applied to every
> >>>
> >>> patch. Partially it is described in [2]. And due to
> >>>
> >>> this process every
> >>>
> >>> patch should not introduce new failures on TC. So,
> >>>
> >>> the patch should
> >>>
> >>> not be merged if inspections failed.
> >>>
> >>> P.S. Something more about prototypes and production
> >>>
> >>> code. There is a
> >>>
> >>> common bad practice in software engineering. It is
> >>>
> >>> turning prototypes
> >>>
> >>> into production code. Often it is much faster to
> >>>
> >>> create a prototype by
> >>>
> >>> price of violating some rules of writing "clean
> >>>
> >>> code". And often
> >>>
> >>> prototype after successful piloting is turned into
> >>>
> >>> production code.
> >>>
> >>> And it is very easy in practice to keep some pieces
> >>>
> >>> of 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"
> >>>
> >>> from the beginning.
> >>>
> >>> So, only ideas are taken from the prototype and a
> >>>
> >>> code is fully
> >>>
> >>> rewritten.
> >>>
> >>> [1]
> >>>
> >>>
> >>> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> >>>
> >>> [2]
> >>>
> >>>
> >>> https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> >>>
> >>>
> >>> ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
> >>>
> >>> maxmuzaf@gmail.com>:
> >>>
> >>>
> >>> Ivan,
> >>>
> >>> As the first implementation of this addition, I'd
> >>>
> >>> prefer to make it
> >>>
> >>> working like _Licenses Headers_ suite check. It
> >>>
> >>> will fail when some
> >>>
> >>> of
> >>>
> >>> the code style checks violated. Moreover, these
> >>>
> >>> licenses header
> >>>
> >>> checks
> >>>
> >>> can be included in the checkstyle plugin
> >>>
> >>> configuration.
> >>>
> >>>
> >>> In general, I'd prefer to have a compilation fail
> >>>
> >>> error with code
> >>>
> >>> style checks and after we will get a stable
> >>>
> >>> checkstyle suite I
> >>>
> >>> propose
> >>>
> >>> to change it in a "compilation error" way. If we
> >>>
> >>> are talking about
> >>>
> >>> the
> >>>
> >>> coding style convenient for most of the community
> >>>
> >>> members I see no
> >>>
> >>> difference with coding sketches or
> >>>
> >>> production-ready branches equally.
> >>>
> >>> Indeed, no one will be against unused imports [or
> >>>
> >>> spaces 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() == 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 <
> >>>
> >>> nizhikov@apache.org>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> Actually, I dont see anything wrong with failing
> >>>
> >>> *compilation*
> >>>
> >>> task.
> >>>
> >>>
> >>> I think one should use project code style for
> >>>
> >>> everyday 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?
> >>>
> >>> ср, 13 февр. 2019 г., 10:11 Petr Ivanov
> >>>
> >>> mr.weider@gmail.com:
> >>>
> >>>
> >>> I guess that was about failing build
> >>>
> >>> configuration with
> >>>
> >>> Checkstype,
> >>>
> >>> not
> >>>
> >>> compilation build itself.
> >>>
> >>> On 12 Feb 2019, at 18:03, Павлухин Иван <
> >>>
> >>> vololo100@gmail.com>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> Folks,
> >>>
> >>> Are you going to fail job compiling Ignite
> >>>
> >>> sources [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
> >>>
> >>> convenient to skip some
> >>>
> >>> style
> >>>
> >>> requirements for such sketches (e.g. well
> >>>
> >>> formed javadocs).
> >>>
> >>>
> >>> [1]
> >>>
> >>>
> >>>
> >>>
> >>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> >>>
> >>>
> >>> пн, 11 февр. 2019 г. в 11:38, Nikolay
> >>>
> >>> Izhikov <
> >>>
> >>> nizhikov@apache.org
> >>>
> >>> :
> >>>
> >>>
> >>> Petr, we should have 1 configuration for
> >>>
> >>> project, may be 1
> >>>
> >>> configuration
> >>>
> >>> per programming language.
> >>>
> >>> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
> >>>
> >>> mr.weider@gmail.com:
> >>>
> >>>
> >>> I was asking about how many build
> >>>
> >>> configuration is intended?
> >>>
> >>> One
> >>>
> >>> for
> >>>
> >>> all
> >>>
> >>> and multiple per module?
> >>>
> >>> With IDEA inspections it was going to be
> >>>
> >>> build 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
> >>>
> >>> build task? And each
> >>>
> >>> module
> >>>
> >>> builds
> >>>
> >>> when it required? If yes, then I propose
> >>>
> >>> to create a task
> >>>
> >>> like
> >>>
> >>> "Licence
> >>>
> >>> check" which will be run for every patch.
> >>>
> >>> My point is that violation of codestyle
> >>>
> >>> should be treated as
> >>>
> >>> hard as
> >>>
> >>> compile error.
> >>>
> >>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
> >>>
> >>> mr.weider@gmail.com
> >>>
> >>> :
> >>>
> >>>
> >>> Is build configuration Inspections
> >>>
> >>> [Core] meant to
> >>>
> >>> transform
> >>>
> >>> into
> >>>
> >>> single
> >>>
> >>> all-modules check build configuration
> >>>
> >>> (without module
> >>>
> >>> subdivision)?
> >>>
> >>>
> >>>
> >>> On 11 Feb 2019, at 11:02, Nikolay
> >>>
> >>> Izhikov <
> >>>
> >>> 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/1065-checkstyle-idea
> >>>
> >>>
> >>> I propose do the following:
> >>>
> >>> 1. Migrate current checks to checkstyle.
> >>> 2. Apply checks to all Ignite modules.
> >>>
> >>> Currently, 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
> >>>
> >>> Apache Ignite"
> >>>
> >>> suite.
> >>>
> >>> Ignite
> >>>
> >>> has
> >>>
> >>> to
> >>>
> >>> fail to build if patch violates
> >>>
> >>> codestyle.
> >>>
> >>>
> >>> вс, 10 февр. 2019 г. в 07:54, Павлухин
> >>>
> >>> Иван <
> >>>
> >>> vololo100@gmail.com>:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> I also think that some warning from
> >>>
> >>> IDEA that some code
> >>>
> >>> style rule
> >>>
> >>> is
> >>>
> >>> violated is a must-have.
> >>>
> >>> вс, 10 февр. 2019 г. в 01:58,
> >>>
> >>> oignatenko <
> >>>
> >>> oignatenko@gridgain.com
> >>>
> >>> :
> >>>
> >>>
> >>> Hi Maxim,
> >>>
> >>> I believe that whatever style checks
> >>>
> >>> we establish at
> >>>
> >>> Teamcity, we
> >>>
> >>> better
> >>>
> >>> take care of making it easy for
> >>>
> >>> developers to find and
> >>>
> >>> fix
> >>>
> >>> violations
> >>>
> >>> in
> >>>
> >>> their typical dev environment (for
> >>>
> >>> Ignite this means, in
> >>>
> >>> IDEA). I
> >>>
> >>> think
> >>>
> >>> it
> >>>
> >>> is important that developers can
> >>>
> >>> maintain 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
> >>>
> >>> just 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
> >>>
> >>> checkstyle - I
> >>>
> >>> recommend
> >>>
> >>> keeping
> >>>
> >>> its
> >>>
> >>> config file somewhere in the project
> >>>
> >>> under version
> >>>
> >>> control.
> >>>
> >>> I
> >>>
> >>> used to
> >>>
> >>> maintain such a shared style config
> >>>
> >>> at one of past jobs
> >>>
> >>> and
> >>>
> >>> after
> >>>
> >>> some
> >>>
> >>> experimenting it turned out most
> >>>
> >>> convenient to have it
> >>>
> >>> this
> >>>
> >>> way -
> >>>
> >>> so
> >>>
> >>> that
> >>>
> >>> developers could easily assess and
> >>>
> >>> discuss style
> >>>
> >>> settings
> >>>
> >>> and keep
> >>>
> >>> track
> >>>
> >>> of
> >>>
> >>> changes in these. (note how Kafka
> >>>
> >>> folks 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
> >>>
> >>> community members.
> >>>
> >>> Moreover, this
> >>>
> >>> suite is no longer checks rules we
> >>>
> >>> previously
> >>>
> >>> 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
> >>>
> >>> consider the Apache Kafka
> >>>
> >>> code
> >>>
> >>> style
> >>>
> >>> [5]
> >>>
> >>> way and configure for the Ignite
> >>>
> >>> project a
> >>>
> >>> maven-checkstyle-plugin
> >>>
> >>> with its own maven profile and run
> >>>
> >>> it simultaneously
> >>>
> >>> with
> >>>
> >>> other
> >>>
> >>> TC.
> >>>
> >>> We
> >>>
> >>> can also enable the previously
> >>>
> >>> configured inspection
> >>>
> >>> rules, so no
> >>>
> >>> coding style violations will be
> >>>
> >>> missed.
> >>>
> >>>
> >>> I see some advantages of using a
> >>>
> >>> maven plugin:
> >>>
> >>> - an IDE agnostic way for code checks
> >>> - can be used with different CI and
> >>>
> >>> build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> >>>
> >>> [2]
> >>>
> >>> https://youtrack.jetbrains.com/issue/TW-58504
> >>>
> >>> [3]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> >>>
> >>> [4]
> >>>
> >>> https://issues.apache.org/jira/browse/IGNITE-11277
> >>>
> >>> [5]
> >>>
> >>> https://github.com/apache/kafka/tree/trunk/checkstyle
> >>>
> >>>
> >>> On Fri, 21 Dec 2018 at 16:03, Petr
> >>>
> >>> Ivanov &lt;
> >>>
> >>>
> >>> mr.weider@
> >>>
> >>>
> >>> &gt; wrote:
> >>>
> >>>
> >>> It seems there is bug in latest
> >>>
> >>> 2018.2 TeamCity
> >>>
> >>> Bug is filed [1]
> >>>
> >>>
> >>> [1]
> >>>
> >>> https://youtrack.jetbrains.com/issue/TW-58504
> >>>
> >>>
> >>> On 19 Dec 2018, at 11:31, Petr
> >>>
> >>> Ivanov &lt;
> >>>
> >>>
> >>> mr.weider@
> >>>
> >>>
> >>> &gt; wrote:
> >>>
> >>>
> >>> Investigating problem, stand by.
> >>>
> >>>
> >>> On 18 Dec 2018, at 19:41, Dmitriy
> >>>
> >>> Pavlov &lt;
> >>>
> >>>
> >>> dpavlov@
> >>>
> >>>
> >>> &gt; 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
> >>>
> >>> next 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
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Ivan Pavlukhin
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best Regards, Vyacheslav D.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best Regards, Vyacheslav D.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best Regards, Vyacheslav D.
> >>>
> >>>
> >>
> >>
> >> --
> >> Best Regards, Vyacheslav D.
> >
>


-- 
Best Regards, Vyacheslav D.

Re: Code inspection

[Petr Ivanov <mr...@gmail.com>]

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=3678000&buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=artifacts&branch_IgniteTests24Java8=%3Cdefault%3E#


> On 23 Apr 2019, at 11:59, Petr Ivanov <mr...@gmail.com> wrote:
> 
> I'll check it.
> 
> 
> Also, please pass TC build for review next time and do not add to Run All without it.
> 
> Thanks!
> 
> 
>> On 23 Apr 2019, at 11:53, Vyacheslav Daradur <da...@gmail.com> wrote:
>> 
>> This is quite strange error, in case of "install" phase it'd be better
>> just add "checkstyle" profile to "Build" [1] configuration.
>> 
>> [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
>> 
>> On Tue, Apr 23, 2019 at 11:43 AM Petr Ivanov <mr...@gmail.com> wrote:
>>> 
>>> The suite is malformed.
>>> If no ~/.m2/repository/org/apache/ignite artifact are installed in system, the build will fail [1]
>>> 
>>> It seems that we should use install instead of validate.
>>> 
>>> 
>>> [1] https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=3677858&_focus=288
>>> 
>>> 
>>> On 23 Apr 2019, at 00:25, Vyacheslav Daradur <da...@gmail.com> wrote:
>>> 
>>> Maxim, I merged your changes to master.
>>> 
>>> 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.
>>> 
>>> Please check that it works as expected once again and announce new
>>> requirements in a separate thread to avoid confusion of community.
>>> 
>>> cc Petr, Pavel (JFYI)
>>> 
>>> [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=buildTypeBranches
>>> 
>>> On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur <da...@gmail.com> wrote:
>>> 
>>> 
>>> Maxim,
>>> 
>>> I left some comments in Jira, let's resolve them and I'll assist you
>>> with merge and TC configuring.
>>> 
>>> On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com> wrote:
>>> 
>>> 
>>> Vyacheslav,
>>> 
>>> Thank you for your interest in making Ignite coding style better.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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;
>>> 
>>> On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <da...@gmail.com> wrote:
>>> 
>>> 
>>> Maxim,
>>> 
>>> I looked through the PR and it looks good to me in general.
>>> 
>>> The only question how it's planned to maintain check styles in 2
>>> different configurations, for IDEA and check style plugin?
>>> 
>>> On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <ma...@gmail.com> wrote:
>>> 
>>> 
>>> Igniters,
>>> 
>>> 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).
>>> 
>>> JIRA: IGNITE-11277 [1]
>>> PR: [3]
>>> Upsource: [4]
>>> 
>>> How can take a look?
>>> 
>>> [1] https://issues.apache.org/jira/browse/IGNITE-11277
>>> [2] http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
>>> [3] https://github.com/apache/ignite/pull/6119
>>> [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
>>> 
>>> On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org> wrote:
>>> 
>>> 
>>> Hi Igniters,
>>> 
>>> I see that a new TeamCity is released: Version: 2018.2.3.
>>> 
>>> Probably it could solve recently introduced problem related to:
>>> Unexpected error during build messages processing in TeamCity;
>>> 
>>> Peter I., could you please check?
>>> 
>>> Sincerely,
>>> Dmitriy Pavlov
>>> 
>>> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
>>> 
>>> 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
>>> today.
>>> 
>>> 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.
>>> 
>>> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
>>> 
>>> 
>>> 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.
>>> 
>>> пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
>>> 
>>> 
>>> +1 to enable code style checks in compile time.
>>> 
>>> We can add option to disable maven codestyle profile with some
>>> 
>>> environment variable.
>>> 
>>> 
>>> Anyone who want violate common project rules in their local branch can
>>> 
>>> set this variable and write some nasty code before push :)
>>> 
>>> 
>>> пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
>>> 
>>> 
>>> 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
>>> 
>>> build stage.
>>> 
>>> - increases a bit the build time procedure
>>> - require additional operations to switch it off for prototyping
>>> 
>>> branches
>>> 
>>> 
>>> + do not require TC.Bot visa if someone of the community doesn't use
>>> 
>>> it
>>> 
>>> + 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
>>> 
>>> needs.
>>> 
>>> 
>>> ---
>>> 
>>> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
>>> 
>>> 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:
>>> ====Quoted text====
>>> 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.
>>> 2. Style check takes some time. With simple checks it is almost
>>> negligible. But it can grow if more checks are involved.
>>> ====End of quoted text====
>>> 
>>> Some clarifications. 1 is about running from IDEA first. 2 is
>>> 
>>> related
>>> 
>>> to opinions that we should involve much more checks, e.g. using
>>> abbreviations.
>>> 
>>> чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
>>> 
>>> 
>>> Ivan,
>>> 
>>> Let's take a look at all the options we have (ordered by the
>>> 
>>> frequency 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
>>> 
>>> checkstyle plugin is used in the <build> 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.
>>> 
>>> 
>>> Back to our use cases:
>>> 
>>> 1. For checking the ready to merge branches we will fail the
>>> 
>>> ~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.
>>> 
>>> 
>>> 2. For the prototyping branches, you can turn off checkstyle in
>>> 
>>> your 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
>>> 
>>> checkstyle enabled profile. The common build action as `mvn clean install
>>> -DskipTests` will activate the profile.
>>> 
>>> 
>>> 4. The checkstyle profile can be disabled explicitly on TC by
>>> 
>>> specifying -P !checkstyle option. A don't see any use cases of it, but it's
>>> completely doable.
>>> 
>>> 
>>> Please, correct me if I've missed something.
>>> 
>>> I propose to merge PR [1] as it is, with the configured set of
>>> 
>>> rules.
>>> 
>>> 
>>> [1] https://github.com/apache/ignite/pull/6119
>>> 
>>> On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
>>> 
>>> wrote:
>>> 
>>> 
>>> Maxim,
>>> 
>>> I like an idea of being IDE agnostic. I am ok with currently
>>> 
>>> enabled
>>> 
>>> 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
>>> 
>>> 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.
>>> 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"
>>> 
>>> which I
>>> 
>>> think is quite useful.
>>> 
>>> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
>>> 
>>> :
>>> 
>>> 
>>> Ivan,
>>> 
>>> I like that Jetbrains inspections are integrated with IDE and
>>> 
>>> TC 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
>>> 
>>> with code
>>> 
>>> style checking. I've checked popular java projects: hadoop,
>>> 
>>> kafka,
>>> 
>>> spark, hive, netty. All of them are using
>>> 
>>> maven-checkstyle-plugin in
>>> 
>>> their <build> 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
>>> 
>>> and
>>> 
>>> SizeReplaceableByIsEmpty (all code style checks [5]). Propose
>>> 
>>> to 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-1018
>>> 
>>> [4]
>>> 
>>> https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
>>> 
>>> [5] http://checkstyle.sourceforge.net/checks.html
>>> 
>>> On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
>>> 
>>> vololo100@gmail.com> 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
>>> 
>>> checkstyle
>>> 
>>> plugin? Is it integrated into IDEA out of box? As I got it
>>> 
>>> additional
>>> 
>>> 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
>>> 
>>> visa. Visa
>>> 
>>> includes result from running inspections job.
>>> 
>>> чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
>>> 
>>> nizhikov@apache.org>:
>>> 
>>> 
>>> 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.
>>> 
>>> 
>>> чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
>>> 
>>> vololo100@gmail.com>:
>>> 
>>> 
>>> Nikolay,
>>> 
>>> Should the community spend TC resources for  prototype?
>>> 
>>> Why not? I think it is not bad idea to run all tests
>>> 
>>> against 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
>>> 
>>> with other
>>> 
>>> Igniters. I think it is the cheapest way to check the
>>> 
>>> idea because the
>>> 
>>> check is fully automated. Requiring a human feedback is
>>> 
>>> much 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
>>> 
>>> skipping tests
>>> 
>>> execution if inspections detect a problem?
>>> 
>>> чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
>>> 
>>> nizhikov@apache.org>:
>>> 
>>> 
>>> 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
>>> 
>>> prototype.
>>> 
>>> 
>>> 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?
>>> 
>>> 
>>> 
>>> ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
>>> 
>>> vololo100@gmail.com>:
>>> 
>>> 
>>> 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
>>> 
>>> outline 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
>>> 
>>> that message).
>>> 
>>> 
>>> We have a document defining code style which every
>>> 
>>> contributor should
>>> 
>>> follow [1]. And many points can be checked
>>> 
>>> automatically. Personally,
>>> 
>>> I do not see much need in writing good javadocs for
>>> 
>>> prototype. Why
>>> 
>>> should I stub it to be able run any build on TC?
>>> 
>>> Also, we a have a review process which should be
>>> 
>>> applied to every
>>> 
>>> patch. Partially it is described in [2]. And due to
>>> 
>>> this process every
>>> 
>>> patch should not introduce new failures on TC. So,
>>> 
>>> the patch should
>>> 
>>> not be merged if inspections failed.
>>> 
>>> P.S. Something more about prototypes and production
>>> 
>>> code. There is a
>>> 
>>> common bad practice in software engineering. It is
>>> 
>>> turning prototypes
>>> 
>>> into production code. Often it is much faster to
>>> 
>>> create a prototype by
>>> 
>>> price of violating some rules of writing "clean
>>> 
>>> code". And often
>>> 
>>> prototype after successful piloting is turned into
>>> 
>>> production code.
>>> 
>>> And it is very easy in practice to keep some pieces
>>> 
>>> of 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"
>>> 
>>> from the beginning.
>>> 
>>> So, only ideas are taken from the prototype and a
>>> 
>>> code is fully
>>> 
>>> rewritten.
>>> 
>>> [1]
>>> 
>>> 
>>> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
>>> 
>>> [2]
>>> 
>>> 
>>> https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
>>> 
>>> 
>>> ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
>>> 
>>> maxmuzaf@gmail.com>:
>>> 
>>> 
>>> Ivan,
>>> 
>>> As the first implementation of this addition, I'd
>>> 
>>> prefer to make it
>>> 
>>> working like _Licenses Headers_ suite check. It
>>> 
>>> will fail when some
>>> 
>>> of
>>> 
>>> the code style checks violated. Moreover, these
>>> 
>>> licenses header
>>> 
>>> checks
>>> 
>>> can be included in the checkstyle plugin
>>> 
>>> configuration.
>>> 
>>> 
>>> In general, I'd prefer to have a compilation fail
>>> 
>>> error with code
>>> 
>>> style checks and after we will get a stable
>>> 
>>> checkstyle suite I
>>> 
>>> propose
>>> 
>>> to change it in a "compilation error" way. If we
>>> 
>>> are talking about
>>> 
>>> the
>>> 
>>> coding style convenient for most of the community
>>> 
>>> members I see no
>>> 
>>> difference with coding sketches or
>>> 
>>> production-ready branches equally.
>>> 
>>> Indeed, no one will be against unused imports [or
>>> 
>>> spaces 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() == 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 <
>>> 
>>> nizhikov@apache.org>
>>> 
>>> wrote:
>>> 
>>> 
>>> Actually, I dont see anything wrong with failing
>>> 
>>> *compilation*
>>> 
>>> task.
>>> 
>>> 
>>> I think one should use project code style for
>>> 
>>> everyday 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?
>>> 
>>> ср, 13 февр. 2019 г., 10:11 Petr Ivanov
>>> 
>>> mr.weider@gmail.com:
>>> 
>>> 
>>> I guess that was about failing build
>>> 
>>> configuration with
>>> 
>>> Checkstype,
>>> 
>>> not
>>> 
>>> compilation build itself.
>>> 
>>> On 12 Feb 2019, at 18:03, Павлухин Иван <
>>> 
>>> vololo100@gmail.com>
>>> 
>>> wrote:
>>> 
>>> 
>>> Folks,
>>> 
>>> Are you going to fail job compiling Ignite
>>> 
>>> sources [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
>>> 
>>> convenient to skip some
>>> 
>>> style
>>> 
>>> requirements for such sketches (e.g. well
>>> 
>>> formed javadocs).
>>> 
>>> 
>>> [1]
>>> 
>>> 
>>> 
>>> 
>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
>>> 
>>> 
>>> пн, 11 февр. 2019 г. в 11:38, Nikolay
>>> 
>>> Izhikov <
>>> 
>>> nizhikov@apache.org
>>> 
>>> :
>>> 
>>> 
>>> Petr, we should have 1 configuration for
>>> 
>>> project, may be 1
>>> 
>>> configuration
>>> 
>>> per programming language.
>>> 
>>> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
>>> 
>>> mr.weider@gmail.com:
>>> 
>>> 
>>> I was asking about how many build
>>> 
>>> configuration is intended?
>>> 
>>> One
>>> 
>>> for
>>> 
>>> all
>>> 
>>> and multiple per module?
>>> 
>>> With IDEA inspections it was going to be
>>> 
>>> build 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
>>> 
>>> build task? And each
>>> 
>>> module
>>> 
>>> builds
>>> 
>>> when it required? If yes, then I propose
>>> 
>>> to create a task
>>> 
>>> like
>>> 
>>> "Licence
>>> 
>>> check" which will be run for every patch.
>>> 
>>> My point is that violation of codestyle
>>> 
>>> should be treated as
>>> 
>>> hard as
>>> 
>>> compile error.
>>> 
>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
>>> 
>>> mr.weider@gmail.com
>>> 
>>> :
>>> 
>>> 
>>> Is build configuration Inspections
>>> 
>>> [Core] meant to
>>> 
>>> transform
>>> 
>>> into
>>> 
>>> single
>>> 
>>> all-modules check build configuration
>>> 
>>> (without module
>>> 
>>> subdivision)?
>>> 
>>> 
>>> 
>>> On 11 Feb 2019, at 11:02, Nikolay
>>> 
>>> Izhikov <
>>> 
>>> 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/1065-checkstyle-idea
>>> 
>>> 
>>> I propose do the following:
>>> 
>>> 1. Migrate current checks to checkstyle.
>>> 2. Apply checks to all Ignite modules.
>>> 
>>> Currently, 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
>>> 
>>> Apache Ignite"
>>> 
>>> suite.
>>> 
>>> Ignite
>>> 
>>> has
>>> 
>>> to
>>> 
>>> fail to build if patch violates
>>> 
>>> codestyle.
>>> 
>>> 
>>> вс, 10 февр. 2019 г. в 07:54, Павлухин
>>> 
>>> Иван <
>>> 
>>> vololo100@gmail.com>:
>>> 
>>> 
>>> Hi,
>>> 
>>> I also think that some warning from
>>> 
>>> IDEA that some code
>>> 
>>> style rule
>>> 
>>> is
>>> 
>>> violated is a must-have.
>>> 
>>> вс, 10 февр. 2019 г. в 01:58,
>>> 
>>> oignatenko <
>>> 
>>> oignatenko@gridgain.com
>>> 
>>> :
>>> 
>>> 
>>> Hi Maxim,
>>> 
>>> I believe that whatever style checks
>>> 
>>> we establish at
>>> 
>>> Teamcity, we
>>> 
>>> better
>>> 
>>> take care of making it easy for
>>> 
>>> developers to find and
>>> 
>>> fix
>>> 
>>> violations
>>> 
>>> in
>>> 
>>> their typical dev environment (for
>>> 
>>> Ignite this means, in
>>> 
>>> IDEA). I
>>> 
>>> think
>>> 
>>> it
>>> 
>>> is important that developers can
>>> 
>>> maintain 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
>>> 
>>> just 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
>>> 
>>> checkstyle - I
>>> 
>>> recommend
>>> 
>>> keeping
>>> 
>>> its
>>> 
>>> config file somewhere in the project
>>> 
>>> under version
>>> 
>>> control.
>>> 
>>> I
>>> 
>>> used to
>>> 
>>> maintain such a shared style config
>>> 
>>> at one of past jobs
>>> 
>>> and
>>> 
>>> after
>>> 
>>> some
>>> 
>>> experimenting it turned out most
>>> 
>>> convenient to have it
>>> 
>>> this
>>> 
>>> way -
>>> 
>>> so
>>> 
>>> that
>>> 
>>> developers could easily assess and
>>> 
>>> discuss style
>>> 
>>> settings
>>> 
>>> and keep
>>> 
>>> track
>>> 
>>> of
>>> 
>>> changes in these. (note how Kafka
>>> 
>>> folks 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
>>> 
>>> community members.
>>> 
>>> Moreover, this
>>> 
>>> suite is no longer checks rules we
>>> 
>>> previously
>>> 
>>> 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
>>> 
>>> consider the Apache Kafka
>>> 
>>> code
>>> 
>>> style
>>> 
>>> [5]
>>> 
>>> way and configure for the Ignite
>>> 
>>> project a
>>> 
>>> maven-checkstyle-plugin
>>> 
>>> with its own maven profile and run
>>> 
>>> it simultaneously
>>> 
>>> with
>>> 
>>> other
>>> 
>>> TC.
>>> 
>>> We
>>> 
>>> can also enable the previously
>>> 
>>> configured inspection
>>> 
>>> rules, so no
>>> 
>>> coding style violations will be
>>> 
>>> missed.
>>> 
>>> 
>>> I see some advantages of using a
>>> 
>>> maven plugin:
>>> 
>>> - an IDE agnostic way for code checks
>>> - can be used with different CI and
>>> 
>>> build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
>>> 
>>> [2]
>>> 
>>> https://youtrack.jetbrains.com/issue/TW-58504
>>> 
>>> [3]
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
>>> 
>>> [4]
>>> 
>>> https://issues.apache.org/jira/browse/IGNITE-11277
>>> 
>>> [5]
>>> 
>>> https://github.com/apache/kafka/tree/trunk/checkstyle
>>> 
>>> 
>>> On Fri, 21 Dec 2018 at 16:03, Petr
>>> 
>>> Ivanov &lt;
>>> 
>>> 
>>> mr.weider@
>>> 
>>> 
>>> &gt; wrote:
>>> 
>>> 
>>> It seems there is bug in latest
>>> 
>>> 2018.2 TeamCity
>>> 
>>> Bug is filed [1]
>>> 
>>> 
>>> [1]
>>> 
>>> https://youtrack.jetbrains.com/issue/TW-58504
>>> 
>>> 
>>> On 19 Dec 2018, at 11:31, Petr
>>> 
>>> Ivanov &lt;
>>> 
>>> 
>>> mr.weider@
>>> 
>>> 
>>> &gt; wrote:
>>> 
>>> 
>>> Investigating problem, stand by.
>>> 
>>> 
>>> On 18 Dec 2018, at 19:41, Dmitriy
>>> 
>>> Pavlov &lt;
>>> 
>>> 
>>> dpavlov@
>>> 
>>> 
>>> &gt; 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
>>> 
>>> next 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
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Best regards,
>>> Ivan Pavlukhin
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Best Regards, Vyacheslav D.
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Best Regards, Vyacheslav D.
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Best Regards, Vyacheslav D.
>>> 
>>> 
>> 
>> 
>> -- 
>> Best Regards, Vyacheslav D.
> 

Re: Code inspection

[Petr Ivanov <mr...@gmail.com>]

I'll check it.


Also, please pass TC build for review next time and do not add to Run All without it.

Thanks!


> On 23 Apr 2019, at 11:53, Vyacheslav Daradur <da...@gmail.com> wrote:
> 
> This is quite strange error, in case of "install" phase it'd be better
> just add "checkstyle" profile to "Build" [1] configuration.
> 
> [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> 
> On Tue, Apr 23, 2019 at 11:43 AM Petr Ivanov <mr...@gmail.com> wrote:
>> 
>> The suite is malformed.
>> If no ~/.m2/repository/org/apache/ignite artifact are installed in system, the build will fail [1]
>> 
>> It seems that we should use install instead of validate.
>> 
>> 
>> [1] https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=3677858&_focus=288
>> 
>> 
>> On 23 Apr 2019, at 00:25, Vyacheslav Daradur <da...@gmail.com> wrote:
>> 
>> Maxim, I merged your changes to master.
>> 
>> 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.
>> 
>> Please check that it works as expected once again and announce new
>> requirements in a separate thread to avoid confusion of community.
>> 
>> cc Petr, Pavel (JFYI)
>> 
>> [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=buildTypeBranches
>> 
>> On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur <da...@gmail.com> wrote:
>> 
>> 
>> Maxim,
>> 
>> I left some comments in Jira, let's resolve them and I'll assist you
>> with merge and TC configuring.
>> 
>> On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com> wrote:
>> 
>> 
>> Vyacheslav,
>> 
>> Thank you for your interest in making Ignite coding style better.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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;
>> 
>> On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <da...@gmail.com> wrote:
>> 
>> 
>> Maxim,
>> 
>> I looked through the PR and it looks good to me in general.
>> 
>> The only question how it's planned to maintain check styles in 2
>> different configurations, for IDEA and check style plugin?
>> 
>> On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <ma...@gmail.com> wrote:
>> 
>> 
>> Igniters,
>> 
>> 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).
>> 
>> JIRA: IGNITE-11277 [1]
>> PR: [3]
>> Upsource: [4]
>> 
>> How can take a look?
>> 
>> [1] https://issues.apache.org/jira/browse/IGNITE-11277
>> [2] http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
>> [3] https://github.com/apache/ignite/pull/6119
>> [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
>> 
>> On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org> wrote:
>> 
>> 
>> Hi Igniters,
>> 
>> I see that a new TeamCity is released: Version: 2018.2.3.
>> 
>> Probably it could solve recently introduced problem related to:
>> Unexpected error during build messages processing in TeamCity;
>> 
>> Peter I., could you please check?
>> 
>> Sincerely,
>> Dmitriy Pavlov
>> 
>> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
>> 
>> 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
>> today.
>> 
>> 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.
>> 
>> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
>> 
>> 
>> 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.
>> 
>> пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
>> 
>> 
>> +1 to enable code style checks in compile time.
>> 
>> We can add option to disable maven codestyle profile with some
>> 
>> environment variable.
>> 
>> 
>> Anyone who want violate common project rules in their local branch can
>> 
>> set this variable and write some nasty code before push :)
>> 
>> 
>> пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
>> 
>> 
>> 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
>> 
>> build stage.
>> 
>> - increases a bit the build time procedure
>> - require additional operations to switch it off for prototyping
>> 
>> branches
>> 
>> 
>> + do not require TC.Bot visa if someone of the community doesn't use
>> 
>> it
>> 
>> + 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
>> 
>> needs.
>> 
>> 
>> ---
>> 
>> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
>> 
>> 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:
>> ====Quoted text====
>> 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.
>> 2. Style check takes some time. With simple checks it is almost
>> negligible. But it can grow if more checks are involved.
>> ====End of quoted text====
>> 
>> Some clarifications. 1 is about running from IDEA first. 2 is
>> 
>> related
>> 
>> to opinions that we should involve much more checks, e.g. using
>> abbreviations.
>> 
>> чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
>> 
>> 
>> Ivan,
>> 
>> Let's take a look at all the options we have (ordered by the
>> 
>> frequency 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
>> 
>> checkstyle plugin is used in the <build> 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.
>> 
>> 
>> Back to our use cases:
>> 
>> 1. For checking the ready to merge branches we will fail the
>> 
>> ~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.
>> 
>> 
>> 2. For the prototyping branches, you can turn off checkstyle in
>> 
>> your 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
>> 
>> checkstyle enabled profile. The common build action as `mvn clean install
>> -DskipTests` will activate the profile.
>> 
>> 
>> 4. The checkstyle profile can be disabled explicitly on TC by
>> 
>> specifying -P !checkstyle option. A don't see any use cases of it, but it's
>> completely doable.
>> 
>> 
>> Please, correct me if I've missed something.
>> 
>> I propose to merge PR [1] as it is, with the configured set of
>> 
>> rules.
>> 
>> 
>> [1] https://github.com/apache/ignite/pull/6119
>> 
>> On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
>> 
>> wrote:
>> 
>> 
>> Maxim,
>> 
>> I like an idea of being IDE agnostic. I am ok with currently
>> 
>> enabled
>> 
>> 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
>> 
>> 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.
>> 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"
>> 
>> which I
>> 
>> think is quite useful.
>> 
>> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
>> 
>> :
>> 
>> 
>> Ivan,
>> 
>> I like that Jetbrains inspections are integrated with IDE and
>> 
>> TC 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
>> 
>> with code
>> 
>> style checking. I've checked popular java projects: hadoop,
>> 
>> kafka,
>> 
>> spark, hive, netty. All of them are using
>> 
>> maven-checkstyle-plugin in
>> 
>> their <build> 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
>> 
>> and
>> 
>> SizeReplaceableByIsEmpty (all code style checks [5]). Propose
>> 
>> to 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-1018
>> 
>> [4]
>> 
>> https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
>> 
>> [5] http://checkstyle.sourceforge.net/checks.html
>> 
>> On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
>> 
>> vololo100@gmail.com> 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
>> 
>> checkstyle
>> 
>> plugin? Is it integrated into IDEA out of box? As I got it
>> 
>> additional
>> 
>> 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
>> 
>> visa. Visa
>> 
>> includes result from running inspections job.
>> 
>> чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
>> 
>> nizhikov@apache.org>:
>> 
>> 
>> 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.
>> 
>> 
>> чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
>> 
>> vololo100@gmail.com>:
>> 
>> 
>> Nikolay,
>> 
>> Should the community spend TC resources for  prototype?
>> 
>> Why not? I think it is not bad idea to run all tests
>> 
>> against 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
>> 
>> with other
>> 
>> Igniters. I think it is the cheapest way to check the
>> 
>> idea because the
>> 
>> check is fully automated. Requiring a human feedback is
>> 
>> much 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
>> 
>> skipping tests
>> 
>> execution if inspections detect a problem?
>> 
>> чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
>> 
>> nizhikov@apache.org>:
>> 
>> 
>> 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
>> 
>> prototype.
>> 
>> 
>> 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?
>> 
>> 
>> 
>> ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
>> 
>> vololo100@gmail.com>:
>> 
>> 
>> 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
>> 
>> outline 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
>> 
>> that message).
>> 
>> 
>> We have a document defining code style which every
>> 
>> contributor should
>> 
>> follow [1]. And many points can be checked
>> 
>> automatically. Personally,
>> 
>> I do not see much need in writing good javadocs for
>> 
>> prototype. Why
>> 
>> should I stub it to be able run any build on TC?
>> 
>> Also, we a have a review process which should be
>> 
>> applied to every
>> 
>> patch. Partially it is described in [2]. And due to
>> 
>> this process every
>> 
>> patch should not introduce new failures on TC. So,
>> 
>> the patch should
>> 
>> not be merged if inspections failed.
>> 
>> P.S. Something more about prototypes and production
>> 
>> code. There is a
>> 
>> common bad practice in software engineering. It is
>> 
>> turning prototypes
>> 
>> into production code. Often it is much faster to
>> 
>> create a prototype by
>> 
>> price of violating some rules of writing "clean
>> 
>> code". And often
>> 
>> prototype after successful piloting is turned into
>> 
>> production code.
>> 
>> And it is very easy in practice to keep some pieces
>> 
>> of 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"
>> 
>> from the beginning.
>> 
>> So, only ideas are taken from the prototype and a
>> 
>> code is fully
>> 
>> rewritten.
>> 
>> [1]
>> 
>> 
>> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
>> 
>> [2]
>> 
>> 
>> https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
>> 
>> 
>> ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
>> 
>> maxmuzaf@gmail.com>:
>> 
>> 
>> Ivan,
>> 
>> As the first implementation of this addition, I'd
>> 
>> prefer to make it
>> 
>> working like _Licenses Headers_ suite check. It
>> 
>> will fail when some
>> 
>> of
>> 
>> the code style checks violated. Moreover, these
>> 
>> licenses header
>> 
>> checks
>> 
>> can be included in the checkstyle plugin
>> 
>> configuration.
>> 
>> 
>> In general, I'd prefer to have a compilation fail
>> 
>> error with code
>> 
>> style checks and after we will get a stable
>> 
>> checkstyle suite I
>> 
>> propose
>> 
>> to change it in a "compilation error" way. If we
>> 
>> are talking about
>> 
>> the
>> 
>> coding style convenient for most of the community
>> 
>> members I see no
>> 
>> difference with coding sketches or
>> 
>> production-ready branches equally.
>> 
>> Indeed, no one will be against unused imports [or
>> 
>> spaces 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() == 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 <
>> 
>> nizhikov@apache.org>
>> 
>> wrote:
>> 
>> 
>> Actually, I dont see anything wrong with failing
>> 
>> *compilation*
>> 
>> task.
>> 
>> 
>> I think one should use project code style for
>> 
>> everyday 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?
>> 
>> ср, 13 февр. 2019 г., 10:11 Petr Ivanov
>> 
>> mr.weider@gmail.com:
>> 
>> 
>> I guess that was about failing build
>> 
>> configuration with
>> 
>> Checkstype,
>> 
>> not
>> 
>> compilation build itself.
>> 
>> On 12 Feb 2019, at 18:03, Павлухин Иван <
>> 
>> vololo100@gmail.com>
>> 
>> wrote:
>> 
>> 
>> Folks,
>> 
>> Are you going to fail job compiling Ignite
>> 
>> sources [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
>> 
>> convenient to skip some
>> 
>> style
>> 
>> requirements for such sketches (e.g. well
>> 
>> formed javadocs).
>> 
>> 
>> [1]
>> 
>> 
>> 
>> 
>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
>> 
>> 
>> пн, 11 февр. 2019 г. в 11:38, Nikolay
>> 
>> Izhikov <
>> 
>> nizhikov@apache.org
>> 
>> :
>> 
>> 
>> Petr, we should have 1 configuration for
>> 
>> project, may be 1
>> 
>> configuration
>> 
>> per programming language.
>> 
>> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
>> 
>> mr.weider@gmail.com:
>> 
>> 
>> I was asking about how many build
>> 
>> configuration is intended?
>> 
>> One
>> 
>> for
>> 
>> all
>> 
>> and multiple per module?
>> 
>> With IDEA inspections it was going to be
>> 
>> build 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
>> 
>> build task? And each
>> 
>> module
>> 
>> builds
>> 
>> when it required? If yes, then I propose
>> 
>> to create a task
>> 
>> like
>> 
>> "Licence
>> 
>> check" which will be run for every patch.
>> 
>> My point is that violation of codestyle
>> 
>> should be treated as
>> 
>> hard as
>> 
>> compile error.
>> 
>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
>> 
>> mr.weider@gmail.com
>> 
>> :
>> 
>> 
>> Is build configuration Inspections
>> 
>> [Core] meant to
>> 
>> transform
>> 
>> into
>> 
>> single
>> 
>> all-modules check build configuration
>> 
>> (without module
>> 
>> subdivision)?
>> 
>> 
>> 
>> On 11 Feb 2019, at 11:02, Nikolay
>> 
>> Izhikov <
>> 
>> 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/1065-checkstyle-idea
>> 
>> 
>> I propose do the following:
>> 
>> 1. Migrate current checks to checkstyle.
>> 2. Apply checks to all Ignite modules.
>> 
>> Currently, 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
>> 
>> Apache Ignite"
>> 
>> suite.
>> 
>> Ignite
>> 
>> has
>> 
>> to
>> 
>> fail to build if patch violates
>> 
>> codestyle.
>> 
>> 
>> вс, 10 февр. 2019 г. в 07:54, Павлухин
>> 
>> Иван <
>> 
>> vololo100@gmail.com>:
>> 
>> 
>> Hi,
>> 
>> I also think that some warning from
>> 
>> IDEA that some code
>> 
>> style rule
>> 
>> is
>> 
>> violated is a must-have.
>> 
>> вс, 10 февр. 2019 г. в 01:58,
>> 
>> oignatenko <
>> 
>> oignatenko@gridgain.com
>> 
>> :
>> 
>> 
>> Hi Maxim,
>> 
>> I believe that whatever style checks
>> 
>> we establish at
>> 
>> Teamcity, we
>> 
>> better
>> 
>> take care of making it easy for
>> 
>> developers to find and
>> 
>> fix
>> 
>> violations
>> 
>> in
>> 
>> their typical dev environment (for
>> 
>> Ignite this means, in
>> 
>> IDEA). I
>> 
>> think
>> 
>> it
>> 
>> is important that developers can
>> 
>> maintain 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
>> 
>> just 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
>> 
>> checkstyle - I
>> 
>> recommend
>> 
>> keeping
>> 
>> its
>> 
>> config file somewhere in the project
>> 
>> under version
>> 
>> control.
>> 
>> I
>> 
>> used to
>> 
>> maintain such a shared style config
>> 
>> at one of past jobs
>> 
>> and
>> 
>> after
>> 
>> some
>> 
>> experimenting it turned out most
>> 
>> convenient to have it
>> 
>> this
>> 
>> way -
>> 
>> so
>> 
>> that
>> 
>> developers could easily assess and
>> 
>> discuss style
>> 
>> settings
>> 
>> and keep
>> 
>> track
>> 
>> of
>> 
>> changes in these. (note how Kafka
>> 
>> folks 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
>> 
>> community members.
>> 
>> Moreover, this
>> 
>> suite is no longer checks rules we
>> 
>> previously
>> 
>> 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
>> 
>> consider the Apache Kafka
>> 
>> code
>> 
>> style
>> 
>> [5]
>> 
>> way and configure for the Ignite
>> 
>> project a
>> 
>> maven-checkstyle-plugin
>> 
>> with its own maven profile and run
>> 
>> it simultaneously
>> 
>> with
>> 
>> other
>> 
>> TC.
>> 
>> We
>> 
>> can also enable the previously
>> 
>> configured inspection
>> 
>> rules, so no
>> 
>> coding style violations will be
>> 
>> missed.
>> 
>> 
>> I see some advantages of using a
>> 
>> maven plugin:
>> 
>> - an IDE agnostic way for code checks
>> - can be used with different CI and
>> 
>> build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
>> 
>> [2]
>> 
>> https://youtrack.jetbrains.com/issue/TW-58504
>> 
>> [3]
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
>> 
>> [4]
>> 
>> https://issues.apache.org/jira/browse/IGNITE-11277
>> 
>> [5]
>> 
>> https://github.com/apache/kafka/tree/trunk/checkstyle
>> 
>> 
>> On Fri, 21 Dec 2018 at 16:03, Petr
>> 
>> Ivanov &lt;
>> 
>> 
>> mr.weider@
>> 
>> 
>> &gt; wrote:
>> 
>> 
>> It seems there is bug in latest
>> 
>> 2018.2 TeamCity
>> 
>> Bug is filed [1]
>> 
>> 
>> [1]
>> 
>> https://youtrack.jetbrains.com/issue/TW-58504
>> 
>> 
>> On 19 Dec 2018, at 11:31, Petr
>> 
>> Ivanov &lt;
>> 
>> 
>> mr.weider@
>> 
>> 
>> &gt; wrote:
>> 
>> 
>> Investigating problem, stand by.
>> 
>> 
>> On 18 Dec 2018, at 19:41, Dmitriy
>> 
>> Pavlov &lt;
>> 
>> 
>> dpavlov@
>> 
>> 
>> &gt; 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
>> 
>> next 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
>> 
>> 
>> 
>> 
>> --
>> Best regards,
>> Ivan Pavlukhin
>> 
>> 
>> 
>> 
>> 
>> --
>> Best Regards, Vyacheslav D.
>> 
>> 
>> 
>> 
>> --
>> Best Regards, Vyacheslav D.
>> 
>> 
>> 
>> 
>> --
>> Best Regards, Vyacheslav D.
>> 
>> 
> 
> 
> -- 
> Best Regards, Vyacheslav D.

Re: Code inspection

[Vyacheslav Daradur <da...@gmail.com>]

This is quite strange error, in case of "install" phase it'd be better
just add "checkstyle" profile to "Build" [1] configuration.

[1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite

On Tue, Apr 23, 2019 at 11:43 AM Petr Ivanov <mr...@gmail.com> wrote:
>
> The suite is malformed.
> If no ~/.m2/repository/org/apache/ignite artifact are installed in system, the build will fail [1]
>
> It seems that we should use install instead of validate.
>
>
> [1] https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=3677858&_focus=288
>
>
> On 23 Apr 2019, at 00:25, Vyacheslav Daradur <da...@gmail.com> wrote:
>
> Maxim, I merged your changes to master.
>
> 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.
>
> Please check that it works as expected once again and announce new
> requirements in a separate thread to avoid confusion of community.
>
> cc Petr, Pavel (JFYI)
>
> [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=buildTypeBranches
>
> On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur <da...@gmail.com> wrote:
>
>
> Maxim,
>
> I left some comments in Jira, let's resolve them and I'll assist you
> with merge and TC configuring.
>
> On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com> wrote:
>
>
> Vyacheslav,
>
> Thank you for your interest in making Ignite coding style better.
>
> 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.
>
> 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.
>
> 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;
>
> On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <da...@gmail.com> wrote:
>
>
> Maxim,
>
> I looked through the PR and it looks good to me in general.
>
> The only question how it's planned to maintain check styles in 2
> different configurations, for IDEA and check style plugin?
>
> On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <ma...@gmail.com> wrote:
>
>
> Igniters,
>
> 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).
>
> JIRA: IGNITE-11277 [1]
> PR: [3]
> Upsource: [4]
>
> How can take a look?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-11277
> [2] http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
> [3] https://github.com/apache/ignite/pull/6119
> [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
>
> On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org> wrote:
>
>
> Hi Igniters,
>
> I see that a new TeamCity is released: Version: 2018.2.3.
>
> Probably it could solve recently introduced problem related to:
> Unexpected error during build messages processing in TeamCity;
>
> Peter I., could you please check?
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
>
> 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
> today.
>
> 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.
>
> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
>
>
> 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.
>
> пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
>
>
> +1 to enable code style checks in compile time.
>
> We can add option to disable maven codestyle profile with some
>
> environment variable.
>
>
> Anyone who want violate common project rules in their local branch can
>
> set this variable and write some nasty code before push :)
>
>
> пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
>
>
> 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
>
> build stage.
>
> - increases a bit the build time procedure
> - require additional operations to switch it off for prototyping
>
> branches
>
>
> + do not require TC.Bot visa if someone of the community doesn't use
>
> it
>
> + 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
>
> needs.
>
>
> ---
>
> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
>
> 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:
> ====Quoted text====
> 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.
> 2. Style check takes some time. With simple checks it is almost
> negligible. But it can grow if more checks are involved.
> ====End of quoted text====
>
> Some clarifications. 1 is about running from IDEA first. 2 is
>
> related
>
> to opinions that we should involve much more checks, e.g. using
> abbreviations.
>
> чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
>
>
> Ivan,
>
> Let's take a look at all the options we have (ordered by the
>
> frequency 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
>
> checkstyle plugin is used in the <build> 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.
>
>
> Back to our use cases:
>
> 1. For checking the ready to merge branches we will fail the
>
> ~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.
>
>
> 2. For the prototyping branches, you can turn off checkstyle in
>
> your 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
>
> checkstyle enabled profile. The common build action as `mvn clean install
> -DskipTests` will activate the profile.
>
>
> 4. The checkstyle profile can be disabled explicitly on TC by
>
> specifying -P !checkstyle option. A don't see any use cases of it, but it's
> completely doable.
>
>
> Please, correct me if I've missed something.
>
> I propose to merge PR [1] as it is, with the configured set of
>
> rules.
>
>
> [1] https://github.com/apache/ignite/pull/6119
>
> On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
>
> wrote:
>
>
> Maxim,
>
> I like an idea of being IDE agnostic. I am ok with currently
>
> enabled
>
> 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
>
> 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.
> 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"
>
> which I
>
> think is quite useful.
>
> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
>
> :
>
>
> Ivan,
>
> I like that Jetbrains inspections are integrated with IDE and
>
> TC 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
>
> with code
>
> style checking. I've checked popular java projects: hadoop,
>
> kafka,
>
> spark, hive, netty. All of them are using
>
> maven-checkstyle-plugin in
>
> their <build> 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
>
> and
>
> SizeReplaceableByIsEmpty (all code style checks [5]). Propose
>
> to 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-1018
>
> [4]
>
> https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
>
> [5] http://checkstyle.sourceforge.net/checks.html
>
> On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
>
> vololo100@gmail.com> 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
>
> checkstyle
>
> plugin? Is it integrated into IDEA out of box? As I got it
>
> additional
>
> 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
>
> visa. Visa
>
> includes result from running inspections job.
>
> чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
>
> nizhikov@apache.org>:
>
>
> 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.
>
>
> чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
>
> vololo100@gmail.com>:
>
>
> Nikolay,
>
> Should the community spend TC resources for  prototype?
>
> Why not? I think it is not bad idea to run all tests
>
> against 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
>
> with other
>
> Igniters. I think it is the cheapest way to check the
>
> idea because the
>
> check is fully automated. Requiring a human feedback is
>
> much 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
>
> skipping tests
>
> execution if inspections detect a problem?
>
> чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
>
> nizhikov@apache.org>:
>
>
> 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
>
> prototype.
>
>
> 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?
>
>
>
> ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
>
> vololo100@gmail.com>:
>
>
> 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
>
> outline 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
>
> that message).
>
>
> We have a document defining code style which every
>
> contributor should
>
> follow [1]. And many points can be checked
>
> automatically. Personally,
>
> I do not see much need in writing good javadocs for
>
> prototype. Why
>
> should I stub it to be able run any build on TC?
>
> Also, we a have a review process which should be
>
> applied to every
>
> patch. Partially it is described in [2]. And due to
>
> this process every
>
> patch should not introduce new failures on TC. So,
>
> the patch should
>
> not be merged if inspections failed.
>
> P.S. Something more about prototypes and production
>
> code. There is a
>
> common bad practice in software engineering. It is
>
> turning prototypes
>
> into production code. Often it is much faster to
>
> create a prototype by
>
> price of violating some rules of writing "clean
>
> code". And often
>
> prototype after successful piloting is turned into
>
> production code.
>
> And it is very easy in practice to keep some pieces
>
> of 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"
>
> from the beginning.
>
> So, only ideas are taken from the prototype and a
>
> code is fully
>
> rewritten.
>
> [1]
>
>
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
>
> [2]
>
>
> https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
>
>
> ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
>
> maxmuzaf@gmail.com>:
>
>
> Ivan,
>
> As the first implementation of this addition, I'd
>
> prefer to make it
>
> working like _Licenses Headers_ suite check. It
>
> will fail when some
>
> of
>
> the code style checks violated. Moreover, these
>
> licenses header
>
> checks
>
> can be included in the checkstyle plugin
>
> configuration.
>
>
> In general, I'd prefer to have a compilation fail
>
> error with code
>
> style checks and after we will get a stable
>
> checkstyle suite I
>
> propose
>
> to change it in a "compilation error" way. If we
>
> are talking about
>
> the
>
> coding style convenient for most of the community
>
> members I see no
>
> difference with coding sketches or
>
> production-ready branches equally.
>
> Indeed, no one will be against unused imports [or
>
> spaces 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() == 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 <
>
> nizhikov@apache.org>
>
> wrote:
>
>
> Actually, I dont see anything wrong with failing
>
> *compilation*
>
> task.
>
>
> I think one should use project code style for
>
> everyday 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?
>
> ср, 13 февр. 2019 г., 10:11 Petr Ivanov
>
> mr.weider@gmail.com:
>
>
> I guess that was about failing build
>
> configuration with
>
> Checkstype,
>
> not
>
> compilation build itself.
>
> On 12 Feb 2019, at 18:03, Павлухин Иван <
>
> vololo100@gmail.com>
>
> wrote:
>
>
> Folks,
>
> Are you going to fail job compiling Ignite
>
> sources [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
>
> convenient to skip some
>
> style
>
> requirements for such sketches (e.g. well
>
> formed javadocs).
>
>
> [1]
>
>
>
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
>
>
> пн, 11 февр. 2019 г. в 11:38, Nikolay
>
> Izhikov <
>
> nizhikov@apache.org
>
> :
>
>
> Petr, we should have 1 configuration for
>
> project, may be 1
>
> configuration
>
> per programming language.
>
> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
>
> mr.weider@gmail.com:
>
>
> I was asking about how many build
>
> configuration is intended?
>
> One
>
> for
>
> all
>
> and multiple per module?
>
> With IDEA inspections it was going to be
>
> build 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
>
> build task? And each
>
> module
>
> builds
>
> when it required? If yes, then I propose
>
> to create a task
>
> like
>
> "Licence
>
> check" which will be run for every patch.
>
> My point is that violation of codestyle
>
> should be treated as
>
> hard as
>
> compile error.
>
> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
>
> mr.weider@gmail.com
>
> :
>
>
> Is build configuration Inspections
>
> [Core] meant to
>
> transform
>
> into
>
> single
>
> all-modules check build configuration
>
> (without module
>
> subdivision)?
>
>
>
> On 11 Feb 2019, at 11:02, Nikolay
>
> Izhikov <
>
> 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/1065-checkstyle-idea
>
>
> I propose do the following:
>
> 1. Migrate current checks to checkstyle.
> 2. Apply checks to all Ignite modules.
>
> Currently, 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
>
> Apache Ignite"
>
> suite.
>
> Ignite
>
> has
>
> to
>
> fail to build if patch violates
>
> codestyle.
>
>
> вс, 10 февр. 2019 г. в 07:54, Павлухин
>
> Иван <
>
> vololo100@gmail.com>:
>
>
> Hi,
>
> I also think that some warning from
>
> IDEA that some code
>
> style rule
>
> is
>
> violated is a must-have.
>
> вс, 10 февр. 2019 г. в 01:58,
>
> oignatenko <
>
> oignatenko@gridgain.com
>
> :
>
>
> Hi Maxim,
>
> I believe that whatever style checks
>
> we establish at
>
> Teamcity, we
>
> better
>
> take care of making it easy for
>
> developers to find and
>
> fix
>
> violations
>
> in
>
> their typical dev environment (for
>
> Ignite this means, in
>
> IDEA). I
>
> think
>
> it
>
> is important that developers can
>
> maintain 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
>
> just 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
>
> checkstyle - I
>
> recommend
>
> keeping
>
> its
>
> config file somewhere in the project
>
> under version
>
> control.
>
> I
>
> used to
>
> maintain such a shared style config
>
> at one of past jobs
>
> and
>
> after
>
> some
>
> experimenting it turned out most
>
> convenient to have it
>
> this
>
> way -
>
> so
>
> that
>
> developers could easily assess and
>
> discuss style
>
> settings
>
> and keep
>
> track
>
> of
>
> changes in these. (note how Kafka
>
> folks 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
>
> community members.
>
> Moreover, this
>
> suite is no longer checks rules we
>
> previously
>
> 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
>
> consider the Apache Kafka
>
> code
>
> style
>
> [5]
>
> way and configure for the Ignite
>
> project a
>
> maven-checkstyle-plugin
>
> with its own maven profile and run
>
> it simultaneously
>
> with
>
> other
>
> TC.
>
> We
>
> can also enable the previously
>
> configured inspection
>
> rules, so no
>
> coding style violations will be
>
> missed.
>
>
> I see some advantages of using a
>
> maven plugin:
>
> - an IDE agnostic way for code checks
> - can be used with different CI and
>
> build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
>
> [2]
>
> https://youtrack.jetbrains.com/issue/TW-58504
>
> [3]
>
>
>
>
>
>
>
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
>
> [4]
>
> https://issues.apache.org/jira/browse/IGNITE-11277
>
> [5]
>
> https://github.com/apache/kafka/tree/trunk/checkstyle
>
>
> On Fri, 21 Dec 2018 at 16:03, Petr
>
> Ivanov &lt;
>
>
> mr.weider@
>
>
> &gt; wrote:
>
>
> It seems there is bug in latest
>
> 2018.2 TeamCity
>
> Bug is filed [1]
>
>
> [1]
>
> https://youtrack.jetbrains.com/issue/TW-58504
>
>
> On 19 Dec 2018, at 11:31, Petr
>
> Ivanov &lt;
>
>
> mr.weider@
>
>
> &gt; wrote:
>
>
> Investigating problem, stand by.
>
>
> On 18 Dec 2018, at 19:41, Dmitriy
>
> Pavlov &lt;
>
>
> dpavlov@
>
>
> &gt; 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
>
> next 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
>
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
>
>
>
>
> --
> Best Regards, Vyacheslav D.
>
>
>
>
> --
> Best Regards, Vyacheslav D.
>
>
>
>
> --
> Best Regards, Vyacheslav D.
>
>


-- 
Best Regards, Vyacheslav D.

Re: Code inspection

[Petr Ivanov <mr...@gmail.com>]

The suite is malformed.
If no ~/.m2/repository/org/apache/ignite artifact are installed in system, the build will fail [1]

It seems that we should use install instead of validate.


[1] https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=3677858&_focus=288 <https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=3677858&_focus=288>


> On 23 Apr 2019, at 00:25, Vyacheslav Daradur <da...@gmail.com> wrote:
> 
> Maxim, I merged your changes to master.
> 
> 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.
> 
> Please check that it works as expected once again and announce new
> requirements in a separate thread to avoid confusion of community.
> 
> cc Petr, Pavel (JFYI)
> 
> [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=buildTypeBranches
> 
> On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur <da...@gmail.com> wrote:
>> 
>> Maxim,
>> 
>> I left some comments in Jira, let's resolve them and I'll assist you
>> with merge and TC configuring.
>> 
>> On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com> wrote:
>>> 
>>> Vyacheslav,
>>> 
>>> Thank you for your interest in making Ignite coding style better.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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;
>>> 
>>> On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <da...@gmail.com> wrote:
>>>> 
>>>> Maxim,
>>>> 
>>>> I looked through the PR and it looks good to me in general.
>>>> 
>>>> The only question how it's planned to maintain check styles in 2
>>>> different configurations, for IDEA and check style plugin?
>>>> 
>>>> On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <ma...@gmail.com> wrote:
>>>>> 
>>>>> Igniters,
>>>>> 
>>>>> 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).
>>>>> 
>>>>> JIRA: IGNITE-11277 [1]
>>>>> PR: [3]
>>>>> Upsource: [4]
>>>>> 
>>>>> How can take a look?
>>>>> 
>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-11277
>>>>> [2] http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
>>>>> [3] https://github.com/apache/ignite/pull/6119
>>>>> [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
>>>>> 
>>>>> On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org> wrote:
>>>>>> 
>>>>>> Hi Igniters,
>>>>>> 
>>>>>> I see that a new TeamCity is released: Version: 2018.2.3.
>>>>>> 
>>>>>> Probably it could solve recently introduced problem related to:
>>>>>> Unexpected error during build messages processing in TeamCity;
>>>>>> 
>>>>>> Peter I., could you please check?
>>>>>> 
>>>>>> Sincerely,
>>>>>> Dmitriy Pavlov
>>>>>> 
>>>>>> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
>>>>>> 
>>>>>>> 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
>>>>>>> today.
>>>>>>> 
>>>>>>> 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.
>>>>>>> 
>>>>>>> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
>>>>>>>> 
>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
>>>>>>>>> 
>>>>>>>>> +1 to enable code style checks in compile time.
>>>>>>>>> 
>>>>>>>>> We can add option to disable maven codestyle profile with some
>>>>>>> environment variable.
>>>>>>>>> 
>>>>>>>>> Anyone who want violate common project rules in their local branch can
>>>>>>> set this variable and write some nasty code before push :)
>>>>>>>>> 
>>>>>>>>> пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
>>>>>>>>>> 
>>>>>>>>>> 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
>>>>>>> build stage.
>>>>>>>>>> - increases a bit the build time procedure
>>>>>>>>>> - require additional operations to switch it off for prototyping
>>>>>>> branches
>>>>>>>>>> 
>>>>>>>>>> + do not require TC.Bot visa if someone of the community doesn't use
>>>>>>> it
>>>>>>>>>> + 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
>>>>>>> needs.
>>>>>>>>>> 
>>>>>>>>>> ---
>>>>>>>>>> 
>>>>>>>>>> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
>>>>>>> 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:
>>>>>>>>>>> ====Quoted text====
>>>>>>>>>>> 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.
>>>>>>>>>>> 2. Style check takes some time. With simple checks it is almost
>>>>>>>>>>> negligible. But it can grow if more checks are involved.
>>>>>>>>>>> ====End of quoted text====
>>>>>>>>>>> 
>>>>>>>>>>> Some clarifications. 1 is about running from IDEA first. 2 is
>>>>>>> related
>>>>>>>>>>> to opinions that we should involve much more checks, e.g. using
>>>>>>>>>>> abbreviations.
>>>>>>>>>>> 
>>>>>>>>>>> чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
>>>>>>>>>>>> 
>>>>>>>>>>>> Ivan,
>>>>>>>>>>>> 
>>>>>>>>>>>> Let's take a look at all the options we have (ordered by the
>>>>>>> frequency 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
>>>>>>> checkstyle plugin is used in the <build> 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.
>>>>>>>>>>>> 
>>>>>>>>>>>> Back to our use cases:
>>>>>>>>>>>> 
>>>>>>>>>>>> 1. For checking the ready to merge branches we will fail the
>>>>>>> ~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.
>>>>>>>>>>>> 
>>>>>>>>>>>> 2. For the prototyping branches, you can turn off checkstyle in
>>>>>>> your 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
>>>>>>> checkstyle enabled profile. The common build action as `mvn clean install
>>>>>>> -DskipTests` will activate the profile.
>>>>>>>>>>>> 
>>>>>>>>>>>> 4. The checkstyle profile can be disabled explicitly on TC by
>>>>>>> specifying -P !checkstyle option. A don't see any use cases of it, but it's
>>>>>>> completely doable.
>>>>>>>>>>>> 
>>>>>>>>>>>> Please, correct me if I've missed something.
>>>>>>>>>>>> 
>>>>>>>>>>>> I propose to merge PR [1] as it is, with the configured set of
>>>>>>> rules.
>>>>>>>>>>>> 
>>>>>>>>>>>> [1] https://github.com/apache/ignite/pull/6119
>>>>>>>>>>>> 
>>>>>>>>>>>> On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Maxim,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I like an idea of being IDE agnostic. I am ok with currently
>>>>>>> enabled
>>>>>>>>>>>>> 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
>>>>>>> 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.
>>>>>>>>>>>>> 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"
>>>>>>> which I
>>>>>>>>>>>>> think is quite useful.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
>>>>>>>> :
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Ivan,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I like that Jetbrains inspections are integrated with IDE and
>>>>>>> TC 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
>>>>>>> with code
>>>>>>>>>>>>>> style checking. I've checked popular java projects: hadoop,
>>>>>>> kafka,
>>>>>>>>>>>>>> spark, hive, netty. All of them are using
>>>>>>> maven-checkstyle-plugin in
>>>>>>>>>>>>>> their <build> 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
>>>>>>> and
>>>>>>>>>>>>>> SizeReplaceableByIsEmpty (all code style checks [5]). Propose
>>>>>>> to 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-1018
>>>>>>>>>>>>>> [4]
>>>>>>> https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
>>>>>>>>>>>>>> [5] http://checkstyle.sourceforge.net/checks.html
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
>>>>>>> vololo100@gmail.com> 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
>>>>>>> checkstyle
>>>>>>>>>>>>>>> plugin? Is it integrated into IDEA out of box? As I got it
>>>>>>> additional
>>>>>>>>>>>>>>> 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
>>>>>>> visa. Visa
>>>>>>>>>>>>>>> includes result from running inspections job.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
>>>>>>> nizhikov@apache.org>:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
>>>>>>> vololo100@gmail.com>:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Nikolay,
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Should the community spend TC resources for  prototype?
>>>>>>>>>>>>>>>>> Why not? I think it is not bad idea to run all tests
>>>>>>> against 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
>>>>>>> with other
>>>>>>>>>>>>>>>>> Igniters. I think it is the cheapest way to check the
>>>>>>> idea because the
>>>>>>>>>>>>>>>>> check is fully automated. Requiring a human feedback is
>>>>>>> much 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
>>>>>>> skipping tests
>>>>>>>>>>>>>>>>> execution if inspections detect a problem?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
>>>>>>> nizhikov@apache.org>:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 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
>>>>>>> prototype.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 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?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
>>>>>>> vololo100@gmail.com>:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 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
>>>>>>> outline 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
>>>>>>> that message).
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> We have a document defining code style which every
>>>>>>> contributor should
>>>>>>>>>>>>>>>>>>> follow [1]. And many points can be checked
>>>>>>> automatically. Personally,
>>>>>>>>>>>>>>>>>>> I do not see much need in writing good javadocs for
>>>>>>> prototype. Why
>>>>>>>>>>>>>>>>>>> should I stub it to be able run any build on TC?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Also, we a have a review process which should be
>>>>>>> applied to every
>>>>>>>>>>>>>>>>>>> patch. Partially it is described in [2]. And due to
>>>>>>> this process every
>>>>>>>>>>>>>>>>>>> patch should not introduce new failures on TC. So,
>>>>>>> the patch should
>>>>>>>>>>>>>>>>>>> not be merged if inspections failed.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> P.S. Something more about prototypes and production
>>>>>>> code. There is a
>>>>>>>>>>>>>>>>>>> common bad practice in software engineering. It is
>>>>>>> turning prototypes
>>>>>>>>>>>>>>>>>>> into production code. Often it is much faster to
>>>>>>> create a prototype by
>>>>>>>>>>>>>>>>>>> price of violating some rules of writing "clean
>>>>>>> code". And often
>>>>>>>>>>>>>>>>>>> prototype after successful piloting is turned into
>>>>>>> production code.
>>>>>>>>>>>>>>>>>>> And it is very easy in practice to keep some pieces
>>>>>>> of 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"
>>>>>>> from the beginning.
>>>>>>>>>>>>>>>>>>> So, only ideas are taken from the prototype and a
>>>>>>> code is fully
>>>>>>>>>>>>>>>>>>> rewritten.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>> 
>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
>>>>>>>>>>>>>>>>>>> [2]
>>>>>>>>>>>>>>>>> 
>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
>>>>>>> maxmuzaf@gmail.com>:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Ivan,
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> As the first implementation of this addition, I'd
>>>>>>> prefer to make it
>>>>>>>>>>>>>>>>>>>> working like _Licenses Headers_ suite check. It
>>>>>>> will fail when some
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>> the code style checks violated. Moreover, these
>>>>>>> licenses header
>>>>>>>>>>>>>>>>> checks
>>>>>>>>>>>>>>>>>>>> can be included in the checkstyle plugin
>>>>>>> configuration.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> In general, I'd prefer to have a compilation fail
>>>>>>> error with code
>>>>>>>>>>>>>>>>>>>> style checks and after we will get a stable
>>>>>>> checkstyle suite I
>>>>>>>>>>>>>>>>> propose
>>>>>>>>>>>>>>>>>>>> to change it in a "compilation error" way. If we
>>>>>>> are talking about
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> coding style convenient for most of the community
>>>>>>> members I see no
>>>>>>>>>>>>>>>>>>>> difference with coding sketches or
>>>>>>> production-ready branches equally.
>>>>>>>>>>>>>>>>>>>> Indeed, no one will be against unused imports [or
>>>>>>> spaces 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() == 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 <
>>>>>>> nizhikov@apache.org>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Actually, I dont see anything wrong with failing
>>>>>>> *compilation*
>>>>>>>>>>>>>>>>> task.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> I think one should use project code style for
>>>>>>> everyday 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?
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> ср, 13 февр. 2019 г., 10:11 Petr Ivanov
>>>>>>> mr.weider@gmail.com:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> I guess that was about failing build
>>>>>>> configuration with
>>>>>>>>>>>>>>>>> Checkstype,
>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>> compilation build itself.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> On 12 Feb 2019, at 18:03, Павлухин Иван <
>>>>>>> vololo100@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Folks,
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Are you going to fail job compiling Ignite
>>>>>>> sources [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
>>>>>>> convenient to skip some
>>>>>>>>>>>>>>>>> style
>>>>>>>>>>>>>>>>>>>>>>> requirements for such sketches (e.g. well
>>>>>>> formed javadocs).
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> пн, 11 февр. 2019 г. в 11:38, Nikolay
>>>>>>> Izhikov <
>>>>>>>>>>>>>>>>> nizhikov@apache.org
>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Petr, we should have 1 configuration for
>>>>>>> project, may be 1
>>>>>>>>>>>>>>>>>>> configuration
>>>>>>>>>>>>>>>>>>>>>>>> per programming language.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
>>>>>>> mr.weider@gmail.com:
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> I was asking about how many build
>>>>>>> configuration is intended?
>>>>>>>>>>>>>>>>> One
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>>>>>>>>>> and multiple per module?
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> With IDEA inspections it was going to be
>>>>>>> build 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
>>>>>>> build task? And each
>>>>>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>>>>>>>>> builds
>>>>>>>>>>>>>>>>>>>>>>>>>> when it required? If yes, then I propose
>>>>>>> to create a task
>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>> "Licence
>>>>>>>>>>>>>>>>>>>>>>>>>> check" which will be run for every patch.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> My point is that violation of codestyle
>>>>>>> should be treated as
>>>>>>>>>>>>>>>>>>> hard as
>>>>>>>>>>>>>>>>>>>>>>>>>> compile error.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
>>>>>>> mr.weider@gmail.com
>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> Is build configuration Inspections
>>>>>>> [Core] meant to
>>>>>>>>>>>>>>>>> transform
>>>>>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>>>>>>>>>>>>>> all-modules check build configuration
>>>>>>> (without module
>>>>>>>>>>>>>>>>>>> subdivision)?
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11 Feb 2019, at 11:02, Nikolay
>>>>>>> Izhikov <
>>>>>>>>>>>>>>>>>>> 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/1065-checkstyle-idea
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I propose do the following:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Migrate current checks to checkstyle.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. Apply checks to all Ignite modules.
>>>>>>> Currently, 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
>>>>>>> Apache Ignite"
>>>>>>>>>>>>>>>>> suite.
>>>>>>>>>>>>>>>>>>> Ignite
>>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> fail to build if patch violates
>>>>>>> codestyle.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин
>>>>>>> Иван <
>>>>>>>>>>>>>>>>>>> vololo100@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I also think that some warning from
>>>>>>> IDEA that some code
>>>>>>>>>>>>>>>>>>> style rule
>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> violated is a must-have.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> вс, 10 февр. 2019 г. в 01:58,
>>>>>>> oignatenko <
>>>>>>>>>>>>>>>>>>> oignatenko@gridgain.com
>>>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Maxim,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I believe that whatever style checks
>>>>>>> we establish at
>>>>>>>>>>>>>>>>>>> Teamcity, we
>>>>>>>>>>>>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> take care of making it easy for
>>>>>>> developers to find and
>>>>>>>>>>>>>>>>> fix
>>>>>>>>>>>>>>>>>>>>>> violations
>>>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> their typical dev environment (for
>>>>>>> Ignite this means, in
>>>>>>>>>>>>>>>>>>> IDEA). I
>>>>>>>>>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is important that developers can
>>>>>>> maintain 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
>>>>>>> just 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
>>>>>>> checkstyle - I
>>>>>>>>>>>>>>>>> recommend
>>>>>>>>>>>>>>>>>>> keeping
>>>>>>>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> config file somewhere in the project
>>>>>>> under version
>>>>>>>>>>>>>>>>> control.
>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>> used to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maintain such a shared style config
>>>>>>> at one of past jobs
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> after
>>>>>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> experimenting it turned out most
>>>>>>> convenient to have it
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> way -
>>>>>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> developers could easily assess and
>>>>>>> discuss style
>>>>>>>>>>>>>>>>> settings
>>>>>>>>>>>>>>>>>>> and keep
>>>>>>>>>>>>>>>>>>>>>>>>>>> track
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> changes in these. (note how Kafka
>>>>>>> folks 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
>>>>>>> community members.
>>>>>>>>>>>>>>>>>>> Moreover, this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> suite is no longer checks rules we
>>>>>>> previously
>>>>>>>>>>>>>>>>> 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
>>>>>>> consider the Apache Kafka
>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>> style
>>>>>>>>>>>>>>>>>>>>>>>>> [5]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way and configure for the Ignite
>>>>>>> project a
>>>>>>>>>>>>>>>>>>>>>> maven-checkstyle-plugin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with its own maven profile and run
>>>>>>> it simultaneously
>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>>>> TC.
>>>>>>>>>>>>>>>>>>>>>>>>> We
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can also enable the previously
>>>>>>> configured inspection
>>>>>>>>>>>>>>>>>>> rules, so no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> coding style violations will be
>>>>>>> missed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I see some advantages of using a
>>>>>>> maven plugin:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - an IDE agnostic way for code checks
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - can be used with different CI and
>>>>>>> build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [2]
>>>>>>> https://youtrack.jetbrains.com/issue/TW-58504
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [3]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [4]
>>>>>>> https://issues.apache.org/jira/browse/IGNITE-11277
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [5]
>>>>>>>>>>>>>>>>> https://github.com/apache/kafka/tree/trunk/checkstyle
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr
>>>>>>> Ivanov &lt;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mr.weider@
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> &gt; wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It seems there is bug in latest
>>>>>>> 2018.2 TeamCity
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bug is filed [1]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>> https://youtrack.jetbrains.com/issue/TW-58504
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr
>>>>>>> Ivanov &lt;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mr.weider@
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> &gt; wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Investigating problem, stand by.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy
>>>>>>> Pavlov &lt;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dpavlov@
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> &gt; 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
>>>>>>> next 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
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> Ivan Pavlukhin
>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best Regards, Vyacheslav D.
>>>> 
>> 
>> 
>> 
>> --
>> Best Regards, Vyacheslav D.
> 
> 
> 
> -- 
> Best Regards, Vyacheslav D.

Re: Code inspection

[Vyacheslav Daradur <da...@gmail.com>]

Maxim, I merged your changes to master.

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.

Please check that it works as expected once again and announce new
requirements in a separate thread to avoid confusion of community.

cc Petr, Pavel (JFYI)

[1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle&tab=buildTypeBranches

On Sun, Apr 21, 2019 at 10:18 PM Vyacheslav Daradur <da...@gmail.com> wrote:
>
> Maxim,
>
> I left some comments in Jira, let's resolve them and I'll assist you
> with merge and TC configuring.
>
> On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com> wrote:
> >
> > Vyacheslav,
> >
> > Thank you for your interest in making Ignite coding style better.
> >
> > 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.
> >
> > 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.
> >
> > 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;
> >
> > On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <da...@gmail.com> wrote:
> > >
> > > Maxim,
> > >
> > > I looked through the PR and it looks good to me in general.
> > >
> > > The only question how it's planned to maintain check styles in 2
> > > different configurations, for IDEA and check style plugin?
> > >
> > > On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <ma...@gmail.com> wrote:
> > > >
> > > > Igniters,
> > > >
> > > > 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).
> > > >
> > > > JIRA: IGNITE-11277 [1]
> > > > PR: [3]
> > > > Upsource: [4]
> > > >
> > > > How can take a look?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-11277
> > > > [2] http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
> > > > [3] https://github.com/apache/ignite/pull/6119
> > > > [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
> > > >
> > > > On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org> wrote:
> > > > >
> > > > > Hi Igniters,
> > > > >
> > > > > I see that a new TeamCity is released: Version: 2018.2.3.
> > > > >
> > > > > Probably it could solve recently introduced problem related to:
> > > > > Unexpected error during build messages processing in TeamCity;
> > > > >
> > > > > Peter I., could you please check?
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > > > >
> > > > > > 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
> > > > > > today.
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
> > > > > > > >
> > > > > > > > +1 to enable code style checks in compile time.
> > > > > > > >
> > > > > > > > We can add option to disable maven codestyle profile with some
> > > > > > environment variable.
> > > > > > > >
> > > > > > > > Anyone who want violate common project rules in their local branch can
> > > > > > set this variable and write some nasty code before push :)
> > > > > > > >
> > > > > > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
> > > > > > > >>
> > > > > > > >> 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
> > > > > > build stage.
> > > > > > > >> - increases a bit the build time procedure
> > > > > > > >> - require additional operations to switch it off for prototyping
> > > > > > branches
> > > > > > > >>
> > > > > > > >> + do not require TC.Bot visa if someone of the community doesn't use
> > > > > > it
> > > > > > > >> + 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
> > > > > > needs.
> > > > > > > >>
> > > > > > > >> ---
> > > > > > > >>
> > > > > > > >> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
> > > > > > 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:
> > > > > > > >> > ====Quoted text====
> > > > > > > >> > 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.
> > > > > > > >> > 2. Style check takes some time. With simple checks it is almost
> > > > > > > >> > negligible. But it can grow if more checks are involved.
> > > > > > > >> > ====End of quoted text====
> > > > > > > >> >
> > > > > > > >> > Some clarifications. 1 is about running from IDEA first. 2 is
> > > > > > related
> > > > > > > >> > to opinions that we should involve much more checks, e.g. using
> > > > > > > >> > abbreviations.
> > > > > > > >> >
> > > > > > > >> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> > > > > > > >> > >
> > > > > > > >> > > Ivan,
> > > > > > > >> > >
> > > > > > > >> > > Let's take a look at all the options we have (ordered by the
> > > > > > frequency 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
> > > > > > checkstyle plugin is used in the <build> 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.
> > > > > > > >> > >
> > > > > > > >> > > Back to our use cases:
> > > > > > > >> > >
> > > > > > > >> > > 1. For checking the ready to merge branches we will fail the
> > > > > > ~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.
> > > > > > > >> > >
> > > > > > > >> > > 2. For the prototyping branches, you can turn off checkstyle in
> > > > > > your 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
> > > > > > checkstyle enabled profile. The common build action as `mvn clean install
> > > > > > -DskipTests` will activate the profile.
> > > > > > > >> > >
> > > > > > > >> > > 4. The checkstyle profile can be disabled explicitly on TC by
> > > > > > specifying -P !checkstyle option. A don't see any use cases of it, but it's
> > > > > > completely doable.
> > > > > > > >> > >
> > > > > > > >> > > Please, correct me if I've missed something.
> > > > > > > >> > >
> > > > > > > >> > > I propose to merge PR [1] as it is, with the configured set of
> > > > > > rules.
> > > > > > > >> > >
> > > > > > > >> > > [1] https://github.com/apache/ignite/pull/6119
> > > > > > > >> > >
> > > > > > > >> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
> > > > > > wrote:
> > > > > > > >> > >>
> > > > > > > >> > >> Maxim,
> > > > > > > >> > >>
> > > > > > > >> > >> I like an idea of being IDE agnostic. I am ok with currently
> > > > > > enabled
> > > > > > > >> > >> 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
> > > > > > 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.
> > > > > > > >> > >> 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"
> > > > > > which I
> > > > > > > >> > >> think is quite useful.
> > > > > > > >> > >>
> > > > > > > >> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
> > > > > > >:
> > > > > > > >> > >> >
> > > > > > > >> > >> > Ivan,
> > > > > > > >> > >> >
> > > > > > > >> > >> > I like that Jetbrains inspections are integrated with IDE and
> > > > > > TC 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
> > > > > > with code
> > > > > > > >> > >> > style checking. I've checked popular java projects: hadoop,
> > > > > > kafka,
> > > > > > > >> > >> > spark, hive, netty. All of them are using
> > > > > > maven-checkstyle-plugin in
> > > > > > > >> > >> > their <build> 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
> > > > > > and
> > > > > > > >> > >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose
> > > > > > to 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-1018
> > > > > > > >> > >> > [4]
> > > > > > https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > > > > > > >> > >> > [5] http://checkstyle.sourceforge.net/checks.html
> > > > > > > >> > >> >
> > > > > > > >> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> > > > > > vololo100@gmail.com> 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
> > > > > > checkstyle
> > > > > > > >> > >> > > plugin? Is it integrated into IDEA out of box? As I got it
> > > > > > additional
> > > > > > > >> > >> > > 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
> > > > > > visa. Visa
> > > > > > > >> > >> > > includes result from running inspections job.
> > > > > > > >> > >> > >
> > > > > > > >> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> > > > > > nizhikov@apache.org>:
> > > > > > > >> > >> > > >
> > > > > > > >> > >> > > > 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.
> > > > > > > >> > >> > > >
> > > > > > > >> > >> > > >
> > > > > > > >> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> > > > > > vololo100@gmail.com>:
> > > > > > > >> > >> > > >
> > > > > > > >> > >> > > > > Nikolay,
> > > > > > > >> > >> > > > >
> > > > > > > >> > >> > > > > > Should the community spend TC resources for  prototype?
> > > > > > > >> > >> > > > > Why not? I think it is not bad idea to run all tests
> > > > > > against 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
> > > > > > with other
> > > > > > > >> > >> > > > > Igniters. I think it is the cheapest way to check the
> > > > > > idea because the
> > > > > > > >> > >> > > > > check is fully automated. Requiring a human feedback is
> > > > > > much 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
> > > > > > skipping tests
> > > > > > > >> > >> > > > > execution if inspections detect a problem?
> > > > > > > >> > >> > > > >
> > > > > > > >> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
> > > > > > nizhikov@apache.org>:
> > > > > > > >> > >> > > > > >
> > > > > > > >> > >> > > > > > 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
> > > > > > prototype.
> > > > > > > >> > >> > > > > >
> > > > > > > >> > >> > > > > > 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?
> > > > > > > >> > >> > > > > >
> > > > > > > >> > >> > > > > >
> > > > > > > >> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
> > > > > > vololo100@gmail.com>:
> > > > > > > >> > >> > > > > >
> > > > > > > >> > >> > > > > > > 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
> > > > > > outline 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
> > > > > > that message).
> > > > > > > >> > >> > > > > > >
> > > > > > > >> > >> > > > > > > We have a document defining code style which every
> > > > > > contributor should
> > > > > > > >> > >> > > > > > > follow [1]. And many points can be checked
> > > > > > automatically. Personally,
> > > > > > > >> > >> > > > > > > I do not see much need in writing good javadocs for
> > > > > > prototype. Why
> > > > > > > >> > >> > > > > > > should I stub it to be able run any build on TC?
> > > > > > > >> > >> > > > > > >
> > > > > > > >> > >> > > > > > > Also, we a have a review process which should be
> > > > > > applied to every
> > > > > > > >> > >> > > > > > > patch. Partially it is described in [2]. And due to
> > > > > > this process every
> > > > > > > >> > >> > > > > > > patch should not introduce new failures on TC. So,
> > > > > > the patch should
> > > > > > > >> > >> > > > > > > not be merged if inspections failed.
> > > > > > > >> > >> > > > > > >
> > > > > > > >> > >> > > > > > > P.S. Something more about prototypes and production
> > > > > > code. There is a
> > > > > > > >> > >> > > > > > > common bad practice in software engineering. It is
> > > > > > turning prototypes
> > > > > > > >> > >> > > > > > > into production code. Often it is much faster to
> > > > > > create a prototype by
> > > > > > > >> > >> > > > > > > price of violating some rules of writing "clean
> > > > > > code". And often
> > > > > > > >> > >> > > > > > > prototype after successful piloting is turned into
> > > > > > production code.
> > > > > > > >> > >> > > > > > > And it is very easy in practice to keep some pieces
> > > > > > of 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"
> > > > > > from the beginning.
> > > > > > > >> > >> > > > > > > So, only ideas are taken from the prototype and a
> > > > > > code is fully
> > > > > > > >> > >> > > > > > > rewritten.
> > > > > > > >> > >> > > > > > >
> > > > > > > >> > >> > > > > > > [1]
> > > > > > > >> > >> > > > >
> > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > > > > >> > >> > > > > > > [2]
> > > > > > > >> > >> > > > >
> > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > > > > >> > >> > > > > > >
> > > > > > > >> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
> > > > > > maxmuzaf@gmail.com>:
> > > > > > > >> > >> > > > > > > >
> > > > > > > >> > >> > > > > > > > Ivan,
> > > > > > > >> > >> > > > > > > >
> > > > > > > >> > >> > > > > > > > As the first implementation of this addition, I'd
> > > > > > prefer to make it
> > > > > > > >> > >> > > > > > > > working like _Licenses Headers_ suite check. It
> > > > > > will fail when some
> > > > > > > >> > >> > > > > of
> > > > > > > >> > >> > > > > > > > the code style checks violated. Moreover, these
> > > > > > licenses header
> > > > > > > >> > >> > > > > checks
> > > > > > > >> > >> > > > > > > > can be included in the checkstyle plugin
> > > > > > configuration.
> > > > > > > >> > >> > > > > > > >
> > > > > > > >> > >> > > > > > > > In general, I'd prefer to have a compilation fail
> > > > > > error with code
> > > > > > > >> > >> > > > > > > > style checks and after we will get a stable
> > > > > > checkstyle suite I
> > > > > > > >> > >> > > > > propose
> > > > > > > >> > >> > > > > > > > to change it in a "compilation error" way. If we
> > > > > > are talking about
> > > > > > > >> > >> > > > > the
> > > > > > > >> > >> > > > > > > > coding style convenient for most of the community
> > > > > > members I see no
> > > > > > > >> > >> > > > > > > > difference with coding sketches or
> > > > > > production-ready branches equally.
> > > > > > > >> > >> > > > > > > > Indeed, no one will be against unused imports [or
> > > > > > spaces 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() == 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 <
> > > > > > nizhikov@apache.org>
> > > > > > > >> > >> > > > > > > wrote:
> > > > > > > >> > >> > > > > > > > >
> > > > > > > >> > >> > > > > > > > > Actually, I dont see anything wrong with failing
> > > > > > *compilation*
> > > > > > > >> > >> > > > > task.
> > > > > > > >> > >> > > > > > > > >
> > > > > > > >> > >> > > > > > > > > I think one should use project code style for
> > > > > > everyday 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?
> > > > > > > >> > >> > > > > > > > >
> > > > > > > >> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov
> > > > > > mr.weider@gmail.com:
> > > > > > > >> > >> > > > > > > > >
> > > > > > > >> > >> > > > > > > > > > I guess that was about failing build
> > > > > > configuration with
> > > > > > > >> > >> > > > > Checkstype,
> > > > > > > >> > >> > > > > > > not
> > > > > > > >> > >> > > > > > > > > > compilation build itself.
> > > > > > > >> > >> > > > > > > > > >
> > > > > > > >> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <
> > > > > > vololo100@gmail.com>
> > > > > > > >> > >> > > > > > > wrote:
> > > > > > > >> > >> > > > > > > > > > >
> > > > > > > >> > >> > > > > > > > > > > Folks,
> > > > > > > >> > >> > > > > > > > > > >
> > > > > > > >> > >> > > > > > > > > > > Are you going to fail job compiling Ignite
> > > > > > sources [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
> > > > > > convenient to skip some
> > > > > > > >> > >> > > > > style
> > > > > > > >> > >> > > > > > > > > > > requirements for such sketches (e.g. well
> > > > > > formed javadocs).
> > > > > > > >> > >> > > > > > > > > > >
> > > > > > > >> > >> > > > > > > > > > > [1]
> > > > > > > >> > >> > > > > > > > > >
> > > > > > > >> > >> > > > > > >
> > > > > > > >> > >> > > > >
> > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > > > >> > >> > > > > > > > > > >
> > > > > > > >> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay
> > > > > > Izhikov <
> > > > > > > >> > >> > > > > nizhikov@apache.org
> > > > > > > >> > >> > > > > > > >:
> > > > > > > >> > >> > > > > > > > > > >>
> > > > > > > >> > >> > > > > > > > > > >> Petr, we should have 1 configuration for
> > > > > > project, may be 1
> > > > > > > >> > >> > > > > > > configuration
> > > > > > > >> > >> > > > > > > > > > >> per programming language.
> > > > > > > >> > >> > > > > > > > > > >>
> > > > > > > >> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
> > > > > > mr.weider@gmail.com:
> > > > > > > >> > >> > > > > > > > > > >>
> > > > > > > >> > >> > > > > > > > > > >>> I was asking about how many build
> > > > > > configuration is intended?
> > > > > > > >> > >> > > > > One
> > > > > > > >> > >> > > > > > > for
> > > > > > > >> > >> > > > > > > > > > all
> > > > > > > >> > >> > > > > > > > > > >>> and multiple per module?
> > > > > > > >> > >> > > > > > > > > > >>>
> > > > > > > >> > >> > > > > > > > > > >>> With IDEA inspections it was going to be
> > > > > > build 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
> > > > > > build task? And each
> > > > > > > >> > >> > > > > > > module
> > > > > > > >> > >> > > > > > > > > > builds
> > > > > > > >> > >> > > > > > > > > > >>>> when it required? If yes, then I propose
> > > > > > to create a task
> > > > > > > >> > >> > > > > like
> > > > > > > >> > >> > > > > > > > > > "Licence
> > > > > > > >> > >> > > > > > > > > > >>>> check" which will be run for every patch.
> > > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > > >> > >> > > > > > > > > > >>>> My point is that violation of codestyle
> > > > > > should be treated as
> > > > > > > >> > >> > > > > > > hard as
> > > > > > > >> > >> > > > > > > > > > >>>> compile error.
> > > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > > >> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
> > > > > > mr.weider@gmail.com
> > > > > > > >> > >> > > > > :
> > > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > > >> > >> > > > > > > > > > >>>>> Is build configuration Inspections
> > > > > > [Core] meant to
> > > > > > > >> > >> > > > > transform
> > > > > > > >> > >> > > > > > > into
> > > > > > > >> > >> > > > > > > > > > single
> > > > > > > >> > >> > > > > > > > > > >>>>> all-modules check build configuration
> > > > > > (without module
> > > > > > > >> > >> > > > > > > subdivision)?
> > > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay
> > > > > > Izhikov <
> > > > > > > >> > >> > > > > > > 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/1065-checkstyle-idea
> > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>> I propose do the following:
> > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > > > > > >> > >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules.
> > > > > > Currently, 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
> > > > > > Apache Ignite"
> > > > > > > >> > >> > > > > suite.
> > > > > > > >> > >> > > > > > > Ignite
> > > > > > > >> > >> > > > > > > > > > has
> > > > > > > >> > >> > > > > > > > > > >>>>> to
> > > > > > > >> > >> > > > > > > > > > >>>>>> fail to build if patch violates
> > > > > > codestyle.
> > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин
> > > > > > Иван <
> > > > > > > >> > >> > > > > > > vololo100@gmail.com>:
> > > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>> Hi,
> > > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>> I also think that some warning from
> > > > > > IDEA that some code
> > > > > > > >> > >> > > > > > > style rule
> > > > > > > >> > >> > > > > > > > > > is
> > > > > > > >> > >> > > > > > > > > > >>>>>>> violated is a must-have.
> > > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58,
> > > > > > oignatenko <
> > > > > > > >> > >> > > > > > > oignatenko@gridgain.com
> > > > > > > >> > >> > > > > > > > > > >:
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>> I believe that whatever style checks
> > > > > > we establish at
> > > > > > > >> > >> > > > > > > Teamcity, we
> > > > > > > >> > >> > > > > > > > > > >>>>> better
> > > > > > > >> > >> > > > > > > > > > >>>>>>>> take care of making it easy for
> > > > > > developers to find and
> > > > > > > >> > >> > > > > fix
> > > > > > > >> > >> > > > > > > > > > violations
> > > > > > > >> > >> > > > > > > > > > >>>>> in
> > > > > > > >> > >> > > > > > > > > > >>>>>>>> their typical dev environment (for
> > > > > > Ignite this means, in
> > > > > > > >> > >> > > > > > > IDEA). I
> > > > > > > >> > >> > > > > > > > > > >>> think
> > > > > > > >> > >> > > > > > > > > > >>>>>>> it
> > > > > > > >> > >> > > > > > > > > > >>>>>>>> is important that developers can
> > > > > > maintain 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
> > > > > > just 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
> > > > > > checkstyle - I
> > > > > > > >> > >> > > > > recommend
> > > > > > > >> > >> > > > > > > keeping
> > > > > > > >> > >> > > > > > > > > > >>> its
> > > > > > > >> > >> > > > > > > > > > >>>>>>>> config file somewhere in the project
> > > > > > under version
> > > > > > > >> > >> > > > > control.
> > > > > > > >> > >> > > > > > > I
> > > > > > > >> > >> > > > > > > > > > used to
> > > > > > > >> > >> > > > > > > > > > >>>>>>>> maintain such a shared style config
> > > > > > at one of past jobs
> > > > > > > >> > >> > > > > and
> > > > > > > >> > >> > > > > > > after
> > > > > > > >> > >> > > > > > > > > > >>> some
> > > > > > > >> > >> > > > > > > > > > >>>>>>>> experimenting it turned out most
> > > > > > convenient to have it
> > > > > > > >> > >> > > > > this
> > > > > > > >> > >> > > > > > > way -
> > > > > > > >> > >> > > > > > > > > > so
> > > > > > > >> > >> > > > > > > > > > >>>>> that
> > > > > > > >> > >> > > > > > > > > > >>>>>>>> developers could easily assess and
> > > > > > discuss style
> > > > > > > >> > >> > > > > settings
> > > > > > > >> > >> > > > > > > and keep
> > > > > > > >> > >> > > > > > > > > > >>>>> track
> > > > > > > >> > >> > > > > > > > > > >>>>>>> of
> > > > > > > >> > >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka
> > > > > > folks 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
> > > > > > community members.
> > > > > > > >> > >> > > > > > > Moreover, this
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we
> > > > > > previously
> > > > > > > >> > >> > > > > 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
> > > > > > consider the Apache Kafka
> > > > > > > >> > >> > > > > > > code
> > > > > > > >> > >> > > > > > > > > > style
> > > > > > > >> > >> > > > > > > > > > >>> [5]
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite
> > > > > > project a
> > > > > > > >> > >> > > > > > > > > > maven-checkstyle-plugin
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> with its own maven profile and run
> > > > > > it simultaneously
> > > > > > > >> > >> > > > > with
> > > > > > > >> > >> > > > > > > other
> > > > > > > >> > >> > > > > > > > > > TC.
> > > > > > > >> > >> > > > > > > > > > >>> We
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> can also enable the previously
> > > > > > configured inspection
> > > > > > > >> > >> > > > > > > rules, so no
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> coding style violations will be
> > > > > > missed.
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> I see some advantages of using a
> > > > > > maven plugin:
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> - can be used with different CI and
> > > > > > build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [2]
> > > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [3]
> > > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > > >> > >> > > > > > > > > > >>>
> > > > > > > >> > >> > > > > > > > > >
> > > > > > > >> > >> > > > > > >
> > > > > > > >> > >> > > > >
> > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [4]
> > > > > > https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> [5]
> > > > > > > >> > >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr
> > > > > > Ivanov &lt;
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest
> > > > > > 2018.2 TeamCity
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>> [1]
> > > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr
> > > > > > Ivanov &lt;
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy
> > > > > > Pavlov &lt;
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> dpavlov@
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; 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
> > > > > > next 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
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Ivan Pavlukhin
> > > > > >
> > > > > >
> > > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.



-- 
Best Regards, Vyacheslav D.

Re: Code inspection

[Vyacheslav Daradur <da...@gmail.com>]

Maxim,

I left some comments in Jira, let's resolve them and I'll assist you
with merge and TC configuring.

On Fri, Apr 19, 2019 at 5:50 PM Maxim Muzafarov <ma...@gmail.com> wrote:
>
> Vyacheslav,
>
> Thank you for your interest in making Ignite coding style better.
>
> 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.
>
> 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.
>
> 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;
>
> On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <da...@gmail.com> wrote:
> >
> > Maxim,
> >
> > I looked through the PR and it looks good to me in general.
> >
> > The only question how it's planned to maintain check styles in 2
> > different configurations, for IDEA and check style plugin?
> >
> > On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <ma...@gmail.com> wrote:
> > >
> > > Igniters,
> > >
> > > 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).
> > >
> > > JIRA: IGNITE-11277 [1]
> > > PR: [3]
> > > Upsource: [4]
> > >
> > > How can take a look?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-11277
> > > [2] http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
> > > [3] https://github.com/apache/ignite/pull/6119
> > > [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
> > >
> > > On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org> wrote:
> > > >
> > > > Hi Igniters,
> > > >
> > > > I see that a new TeamCity is released: Version: 2018.2.3.
> > > >
> > > > Probably it could solve recently introduced problem related to:
> > > > Unexpected error during build messages processing in TeamCity;
> > > >
> > > > Peter I., could you please check?
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > > >
> > > > > 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
> > > > > today.
> > > > >
> > > > > 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.
> > > > >
> > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
> > > > > > >
> > > > > > > +1 to enable code style checks in compile time.
> > > > > > >
> > > > > > > We can add option to disable maven codestyle profile with some
> > > > > environment variable.
> > > > > > >
> > > > > > > Anyone who want violate common project rules in their local branch can
> > > > > set this variable and write some nasty code before push :)
> > > > > > >
> > > > > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
> > > > > > >>
> > > > > > >> 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
> > > > > build stage.
> > > > > > >> - increases a bit the build time procedure
> > > > > > >> - require additional operations to switch it off for prototyping
> > > > > branches
> > > > > > >>
> > > > > > >> + do not require TC.Bot visa if someone of the community doesn't use
> > > > > it
> > > > > > >> + 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
> > > > > needs.
> > > > > > >>
> > > > > > >> ---
> > > > > > >>
> > > > > > >> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
> > > > > 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:
> > > > > > >> > ====Quoted text====
> > > > > > >> > 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.
> > > > > > >> > 2. Style check takes some time. With simple checks it is almost
> > > > > > >> > negligible. But it can grow if more checks are involved.
> > > > > > >> > ====End of quoted text====
> > > > > > >> >
> > > > > > >> > Some clarifications. 1 is about running from IDEA first. 2 is
> > > > > related
> > > > > > >> > to opinions that we should involve much more checks, e.g. using
> > > > > > >> > abbreviations.
> > > > > > >> >
> > > > > > >> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> > > > > > >> > >
> > > > > > >> > > Ivan,
> > > > > > >> > >
> > > > > > >> > > Let's take a look at all the options we have (ordered by the
> > > > > frequency 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
> > > > > checkstyle plugin is used in the <build> 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.
> > > > > > >> > >
> > > > > > >> > > Back to our use cases:
> > > > > > >> > >
> > > > > > >> > > 1. For checking the ready to merge branches we will fail the
> > > > > ~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.
> > > > > > >> > >
> > > > > > >> > > 2. For the prototyping branches, you can turn off checkstyle in
> > > > > your 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
> > > > > checkstyle enabled profile. The common build action as `mvn clean install
> > > > > -DskipTests` will activate the profile.
> > > > > > >> > >
> > > > > > >> > > 4. The checkstyle profile can be disabled explicitly on TC by
> > > > > specifying -P !checkstyle option. A don't see any use cases of it, but it's
> > > > > completely doable.
> > > > > > >> > >
> > > > > > >> > > Please, correct me if I've missed something.
> > > > > > >> > >
> > > > > > >> > > I propose to merge PR [1] as it is, with the configured set of
> > > > > rules.
> > > > > > >> > >
> > > > > > >> > > [1] https://github.com/apache/ignite/pull/6119
> > > > > > >> > >
> > > > > > >> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
> > > > > wrote:
> > > > > > >> > >>
> > > > > > >> > >> Maxim,
> > > > > > >> > >>
> > > > > > >> > >> I like an idea of being IDE agnostic. I am ok with currently
> > > > > enabled
> > > > > > >> > >> 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
> > > > > 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.
> > > > > > >> > >> 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"
> > > > > which I
> > > > > > >> > >> think is quite useful.
> > > > > > >> > >>
> > > > > > >> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
> > > > > >:
> > > > > > >> > >> >
> > > > > > >> > >> > Ivan,
> > > > > > >> > >> >
> > > > > > >> > >> > I like that Jetbrains inspections are integrated with IDE and
> > > > > TC 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
> > > > > with code
> > > > > > >> > >> > style checking. I've checked popular java projects: hadoop,
> > > > > kafka,
> > > > > > >> > >> > spark, hive, netty. All of them are using
> > > > > maven-checkstyle-plugin in
> > > > > > >> > >> > their <build> 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
> > > > > and
> > > > > > >> > >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose
> > > > > to 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-1018
> > > > > > >> > >> > [4]
> > > > > https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > > > > > >> > >> > [5] http://checkstyle.sourceforge.net/checks.html
> > > > > > >> > >> >
> > > > > > >> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> > > > > vololo100@gmail.com> 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
> > > > > checkstyle
> > > > > > >> > >> > > plugin? Is it integrated into IDEA out of box? As I got it
> > > > > additional
> > > > > > >> > >> > > 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
> > > > > visa. Visa
> > > > > > >> > >> > > includes result from running inspections job.
> > > > > > >> > >> > >
> > > > > > >> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> > > > > nizhikov@apache.org>:
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > 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.
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> > > > > vololo100@gmail.com>:
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > > Nikolay,
> > > > > > >> > >> > > > >
> > > > > > >> > >> > > > > > Should the community spend TC resources for  prototype?
> > > > > > >> > >> > > > > Why not? I think it is not bad idea to run all tests
> > > > > against 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
> > > > > with other
> > > > > > >> > >> > > > > Igniters. I think it is the cheapest way to check the
> > > > > idea because the
> > > > > > >> > >> > > > > check is fully automated. Requiring a human feedback is
> > > > > much 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
> > > > > skipping tests
> > > > > > >> > >> > > > > execution if inspections detect a problem?
> > > > > > >> > >> > > > >
> > > > > > >> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
> > > > > nizhikov@apache.org>:
> > > > > > >> > >> > > > > >
> > > > > > >> > >> > > > > > 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
> > > > > prototype.
> > > > > > >> > >> > > > > >
> > > > > > >> > >> > > > > > 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?
> > > > > > >> > >> > > > > >
> > > > > > >> > >> > > > > >
> > > > > > >> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
> > > > > vololo100@gmail.com>:
> > > > > > >> > >> > > > > >
> > > > > > >> > >> > > > > > > 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
> > > > > outline 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
> > > > > that message).
> > > > > > >> > >> > > > > > >
> > > > > > >> > >> > > > > > > We have a document defining code style which every
> > > > > contributor should
> > > > > > >> > >> > > > > > > follow [1]. And many points can be checked
> > > > > automatically. Personally,
> > > > > > >> > >> > > > > > > I do not see much need in writing good javadocs for
> > > > > prototype. Why
> > > > > > >> > >> > > > > > > should I stub it to be able run any build on TC?
> > > > > > >> > >> > > > > > >
> > > > > > >> > >> > > > > > > Also, we a have a review process which should be
> > > > > applied to every
> > > > > > >> > >> > > > > > > patch. Partially it is described in [2]. And due to
> > > > > this process every
> > > > > > >> > >> > > > > > > patch should not introduce new failures on TC. So,
> > > > > the patch should
> > > > > > >> > >> > > > > > > not be merged if inspections failed.
> > > > > > >> > >> > > > > > >
> > > > > > >> > >> > > > > > > P.S. Something more about prototypes and production
> > > > > code. There is a
> > > > > > >> > >> > > > > > > common bad practice in software engineering. It is
> > > > > turning prototypes
> > > > > > >> > >> > > > > > > into production code. Often it is much faster to
> > > > > create a prototype by
> > > > > > >> > >> > > > > > > price of violating some rules of writing "clean
> > > > > code". And often
> > > > > > >> > >> > > > > > > prototype after successful piloting is turned into
> > > > > production code.
> > > > > > >> > >> > > > > > > And it is very easy in practice to keep some pieces
> > > > > of 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"
> > > > > from the beginning.
> > > > > > >> > >> > > > > > > So, only ideas are taken from the prototype and a
> > > > > code is fully
> > > > > > >> > >> > > > > > > rewritten.
> > > > > > >> > >> > > > > > >
> > > > > > >> > >> > > > > > > [1]
> > > > > > >> > >> > > > >
> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > > > >> > >> > > > > > > [2]
> > > > > > >> > >> > > > >
> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > > > >> > >> > > > > > >
> > > > > > >> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
> > > > > maxmuzaf@gmail.com>:
> > > > > > >> > >> > > > > > > >
> > > > > > >> > >> > > > > > > > Ivan,
> > > > > > >> > >> > > > > > > >
> > > > > > >> > >> > > > > > > > As the first implementation of this addition, I'd
> > > > > prefer to make it
> > > > > > >> > >> > > > > > > > working like _Licenses Headers_ suite check. It
> > > > > will fail when some
> > > > > > >> > >> > > > > of
> > > > > > >> > >> > > > > > > > the code style checks violated. Moreover, these
> > > > > licenses header
> > > > > > >> > >> > > > > checks
> > > > > > >> > >> > > > > > > > can be included in the checkstyle plugin
> > > > > configuration.
> > > > > > >> > >> > > > > > > >
> > > > > > >> > >> > > > > > > > In general, I'd prefer to have a compilation fail
> > > > > error with code
> > > > > > >> > >> > > > > > > > style checks and after we will get a stable
> > > > > checkstyle suite I
> > > > > > >> > >> > > > > propose
> > > > > > >> > >> > > > > > > > to change it in a "compilation error" way. If we
> > > > > are talking about
> > > > > > >> > >> > > > > the
> > > > > > >> > >> > > > > > > > coding style convenient for most of the community
> > > > > members I see no
> > > > > > >> > >> > > > > > > > difference with coding sketches or
> > > > > production-ready branches equally.
> > > > > > >> > >> > > > > > > > Indeed, no one will be against unused imports [or
> > > > > spaces 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() == 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 <
> > > > > nizhikov@apache.org>
> > > > > > >> > >> > > > > > > wrote:
> > > > > > >> > >> > > > > > > > >
> > > > > > >> > >> > > > > > > > > Actually, I dont see anything wrong with failing
> > > > > *compilation*
> > > > > > >> > >> > > > > task.
> > > > > > >> > >> > > > > > > > >
> > > > > > >> > >> > > > > > > > > I think one should use project code style for
> > > > > everyday 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?
> > > > > > >> > >> > > > > > > > >
> > > > > > >> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov
> > > > > mr.weider@gmail.com:
> > > > > > >> > >> > > > > > > > >
> > > > > > >> > >> > > > > > > > > > I guess that was about failing build
> > > > > configuration with
> > > > > > >> > >> > > > > Checkstype,
> > > > > > >> > >> > > > > > > not
> > > > > > >> > >> > > > > > > > > > compilation build itself.
> > > > > > >> > >> > > > > > > > > >
> > > > > > >> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <
> > > > > vololo100@gmail.com>
> > > > > > >> > >> > > > > > > wrote:
> > > > > > >> > >> > > > > > > > > > >
> > > > > > >> > >> > > > > > > > > > > Folks,
> > > > > > >> > >> > > > > > > > > > >
> > > > > > >> > >> > > > > > > > > > > Are you going to fail job compiling Ignite
> > > > > sources [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
> > > > > convenient to skip some
> > > > > > >> > >> > > > > style
> > > > > > >> > >> > > > > > > > > > > requirements for such sketches (e.g. well
> > > > > formed javadocs).
> > > > > > >> > >> > > > > > > > > > >
> > > > > > >> > >> > > > > > > > > > > [1]
> > > > > > >> > >> > > > > > > > > >
> > > > > > >> > >> > > > > > >
> > > > > > >> > >> > > > >
> > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > > >> > >> > > > > > > > > > >
> > > > > > >> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay
> > > > > Izhikov <
> > > > > > >> > >> > > > > nizhikov@apache.org
> > > > > > >> > >> > > > > > > >:
> > > > > > >> > >> > > > > > > > > > >>
> > > > > > >> > >> > > > > > > > > > >> Petr, we should have 1 configuration for
> > > > > project, may be 1
> > > > > > >> > >> > > > > > > configuration
> > > > > > >> > >> > > > > > > > > > >> per programming language.
> > > > > > >> > >> > > > > > > > > > >>
> > > > > > >> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
> > > > > mr.weider@gmail.com:
> > > > > > >> > >> > > > > > > > > > >>
> > > > > > >> > >> > > > > > > > > > >>> I was asking about how many build
> > > > > configuration is intended?
> > > > > > >> > >> > > > > One
> > > > > > >> > >> > > > > > > for
> > > > > > >> > >> > > > > > > > > > all
> > > > > > >> > >> > > > > > > > > > >>> and multiple per module?
> > > > > > >> > >> > > > > > > > > > >>>
> > > > > > >> > >> > > > > > > > > > >>> With IDEA inspections it was going to be
> > > > > build 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
> > > > > build task? And each
> > > > > > >> > >> > > > > > > module
> > > > > > >> > >> > > > > > > > > > builds
> > > > > > >> > >> > > > > > > > > > >>>> when it required? If yes, then I propose
> > > > > to create a task
> > > > > > >> > >> > > > > like
> > > > > > >> > >> > > > > > > > > > "Licence
> > > > > > >> > >> > > > > > > > > > >>>> check" which will be run for every patch.
> > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > >> > >> > > > > > > > > > >>>> My point is that violation of codestyle
> > > > > should be treated as
> > > > > > >> > >> > > > > > > hard as
> > > > > > >> > >> > > > > > > > > > >>>> compile error.
> > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > >> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
> > > > > mr.weider@gmail.com
> > > > > > >> > >> > > > > :
> > > > > > >> > >> > > > > > > > > > >>>>
> > > > > > >> > >> > > > > > > > > > >>>>> Is build configuration Inspections
> > > > > [Core] meant to
> > > > > > >> > >> > > > > transform
> > > > > > >> > >> > > > > > > into
> > > > > > >> > >> > > > > > > > > > single
> > > > > > >> > >> > > > > > > > > > >>>>> all-modules check build configuration
> > > > > (without module
> > > > > > >> > >> > > > > > > subdivision)?
> > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay
> > > > > Izhikov <
> > > > > > >> > >> > > > > > > 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/1065-checkstyle-idea
> > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>> I propose do the following:
> > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > > > > >> > >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules.
> > > > > Currently, 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
> > > > > Apache Ignite"
> > > > > > >> > >> > > > > suite.
> > > > > > >> > >> > > > > > > Ignite
> > > > > > >> > >> > > > > > > > > > has
> > > > > > >> > >> > > > > > > > > > >>>>> to
> > > > > > >> > >> > > > > > > > > > >>>>>> fail to build if patch violates
> > > > > codestyle.
> > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин
> > > > > Иван <
> > > > > > >> > >> > > > > > > vololo100@gmail.com>:
> > > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>> Hi,
> > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>> I also think that some warning from
> > > > > IDEA that some code
> > > > > > >> > >> > > > > > > style rule
> > > > > > >> > >> > > > > > > > > > is
> > > > > > >> > >> > > > > > > > > > >>>>>>> violated is a must-have.
> > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58,
> > > > > oignatenko <
> > > > > > >> > >> > > > > > > oignatenko@gridgain.com
> > > > > > >> > >> > > > > > > > > > >:
> > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
> > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>> I believe that whatever style checks
> > > > > we establish at
> > > > > > >> > >> > > > > > > Teamcity, we
> > > > > > >> > >> > > > > > > > > > >>>>> better
> > > > > > >> > >> > > > > > > > > > >>>>>>>> take care of making it easy for
> > > > > developers to find and
> > > > > > >> > >> > > > > fix
> > > > > > >> > >> > > > > > > > > > violations
> > > > > > >> > >> > > > > > > > > > >>>>> in
> > > > > > >> > >> > > > > > > > > > >>>>>>>> their typical dev environment (for
> > > > > Ignite this means, in
> > > > > > >> > >> > > > > > > IDEA). I
> > > > > > >> > >> > > > > > > > > > >>> think
> > > > > > >> > >> > > > > > > > > > >>>>>>> it
> > > > > > >> > >> > > > > > > > > > >>>>>>>> is important that developers can
> > > > > maintain 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
> > > > > just 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
> > > > > checkstyle - I
> > > > > > >> > >> > > > > recommend
> > > > > > >> > >> > > > > > > keeping
> > > > > > >> > >> > > > > > > > > > >>> its
> > > > > > >> > >> > > > > > > > > > >>>>>>>> config file somewhere in the project
> > > > > under version
> > > > > > >> > >> > > > > control.
> > > > > > >> > >> > > > > > > I
> > > > > > >> > >> > > > > > > > > > used to
> > > > > > >> > >> > > > > > > > > > >>>>>>>> maintain such a shared style config
> > > > > at one of past jobs
> > > > > > >> > >> > > > > and
> > > > > > >> > >> > > > > > > after
> > > > > > >> > >> > > > > > > > > > >>> some
> > > > > > >> > >> > > > > > > > > > >>>>>>>> experimenting it turned out most
> > > > > convenient to have it
> > > > > > >> > >> > > > > this
> > > > > > >> > >> > > > > > > way -
> > > > > > >> > >> > > > > > > > > > so
> > > > > > >> > >> > > > > > > > > > >>>>> that
> > > > > > >> > >> > > > > > > > > > >>>>>>>> developers could easily assess and
> > > > > discuss style
> > > > > > >> > >> > > > > settings
> > > > > > >> > >> > > > > > > and keep
> > > > > > >> > >> > > > > > > > > > >>>>> track
> > > > > > >> > >> > > > > > > > > > >>>>>>> of
> > > > > > >> > >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka
> > > > > folks 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
> > > > > community members.
> > > > > > >> > >> > > > > > > Moreover, this
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we
> > > > > previously
> > > > > > >> > >> > > > > 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
> > > > > consider the Apache Kafka
> > > > > > >> > >> > > > > > > code
> > > > > > >> > >> > > > > > > > > > style
> > > > > > >> > >> > > > > > > > > > >>> [5]
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite
> > > > > project a
> > > > > > >> > >> > > > > > > > > > maven-checkstyle-plugin
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> with its own maven profile and run
> > > > > it simultaneously
> > > > > > >> > >> > > > > with
> > > > > > >> > >> > > > > > > other
> > > > > > >> > >> > > > > > > > > > TC.
> > > > > > >> > >> > > > > > > > > > >>> We
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> can also enable the previously
> > > > > configured inspection
> > > > > > >> > >> > > > > > > rules, so no
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> coding style violations will be
> > > > > missed.
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> I see some advantages of using a
> > > > > maven plugin:
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> - can be used with different CI and
> > > > > build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> [2]
> > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> [3]
> > > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>
> > > > > > >> > >> > > > > > > > > > >>>
> > > > > > >> > >> > > > > > > > > >
> > > > > > >> > >> > > > > > >
> > > > > > >> > >> > > > >
> > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> [4]
> > > > > https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> [5]
> > > > > > >> > >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr
> > > > > Ivanov &lt;
> > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest
> > > > > 2018.2 TeamCity
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>> [1]
> > > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr
> > > > > Ivanov &lt;
> > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy
> > > > > Pavlov &lt;
> > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> dpavlov@
> > > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; 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
> > > > > next 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
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > > >
> > > > >
> > >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >



-- 
Best Regards, Vyacheslav D.

Re: Code inspection

[Maxim Muzafarov <ma...@gmail.com>]

Vyacheslav,

Thank you for your interest in making Ignite coding style better.

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.

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.

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;

On Wed, 17 Apr 2019 at 21:23, Vyacheslav Daradur <da...@gmail.com> wrote:
>
> Maxim,
>
> I looked through the PR and it looks good to me in general.
>
> The only question how it's planned to maintain check styles in 2
> different configurations, for IDEA and check style plugin?
>
> On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <ma...@gmail.com> wrote:
> >
> > Igniters,
> >
> > 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).
> >
> > JIRA: IGNITE-11277 [1]
> > PR: [3]
> > Upsource: [4]
> >
> > How can take a look?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-11277
> > [2] http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
> > [3] https://github.com/apache/ignite/pull/6119
> > [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
> >
> > On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org> wrote:
> > >
> > > Hi Igniters,
> > >
> > > I see that a new TeamCity is released: Version: 2018.2.3.
> > >
> > > Probably it could solve recently introduced problem related to:
> > > Unexpected error during build messages processing in TeamCity;
> > >
> > > Peter I., could you please check?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > >
> > > > 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
> > > > today.
> > > >
> > > > 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.
> > > >
> > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > > > >
> > > > > 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.
> > > > >
> > > > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
> > > > > >
> > > > > > +1 to enable code style checks in compile time.
> > > > > >
> > > > > > We can add option to disable maven codestyle profile with some
> > > > environment variable.
> > > > > >
> > > > > > Anyone who want violate common project rules in their local branch can
> > > > set this variable and write some nasty code before push :)
> > > > > >
> > > > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
> > > > > >>
> > > > > >> 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
> > > > build stage.
> > > > > >> - increases a bit the build time procedure
> > > > > >> - require additional operations to switch it off for prototyping
> > > > branches
> > > > > >>
> > > > > >> + do not require TC.Bot visa if someone of the community doesn't use
> > > > it
> > > > > >> + 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
> > > > needs.
> > > > > >>
> > > > > >> ---
> > > > > >>
> > > > > >> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
> > > > 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:
> > > > > >> > ====Quoted text====
> > > > > >> > 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.
> > > > > >> > 2. Style check takes some time. With simple checks it is almost
> > > > > >> > negligible. But it can grow if more checks are involved.
> > > > > >> > ====End of quoted text====
> > > > > >> >
> > > > > >> > Some clarifications. 1 is about running from IDEA first. 2 is
> > > > related
> > > > > >> > to opinions that we should involve much more checks, e.g. using
> > > > > >> > abbreviations.
> > > > > >> >
> > > > > >> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> > > > > >> > >
> > > > > >> > > Ivan,
> > > > > >> > >
> > > > > >> > > Let's take a look at all the options we have (ordered by the
> > > > frequency 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
> > > > checkstyle plugin is used in the <build> 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.
> > > > > >> > >
> > > > > >> > > Back to our use cases:
> > > > > >> > >
> > > > > >> > > 1. For checking the ready to merge branches we will fail the
> > > > ~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.
> > > > > >> > >
> > > > > >> > > 2. For the prototyping branches, you can turn off checkstyle in
> > > > your 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
> > > > checkstyle enabled profile. The common build action as `mvn clean install
> > > > -DskipTests` will activate the profile.
> > > > > >> > >
> > > > > >> > > 4. The checkstyle profile can be disabled explicitly on TC by
> > > > specifying -P !checkstyle option. A don't see any use cases of it, but it's
> > > > completely doable.
> > > > > >> > >
> > > > > >> > > Please, correct me if I've missed something.
> > > > > >> > >
> > > > > >> > > I propose to merge PR [1] as it is, with the configured set of
> > > > rules.
> > > > > >> > >
> > > > > >> > > [1] https://github.com/apache/ignite/pull/6119
> > > > > >> > >
> > > > > >> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
> > > > wrote:
> > > > > >> > >>
> > > > > >> > >> Maxim,
> > > > > >> > >>
> > > > > >> > >> I like an idea of being IDE agnostic. I am ok with currently
> > > > enabled
> > > > > >> > >> 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
> > > > 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.
> > > > > >> > >> 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"
> > > > which I
> > > > > >> > >> think is quite useful.
> > > > > >> > >>
> > > > > >> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
> > > > >:
> > > > > >> > >> >
> > > > > >> > >> > Ivan,
> > > > > >> > >> >
> > > > > >> > >> > I like that Jetbrains inspections are integrated with IDE and
> > > > TC 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
> > > > with code
> > > > > >> > >> > style checking. I've checked popular java projects: hadoop,
> > > > kafka,
> > > > > >> > >> > spark, hive, netty. All of them are using
> > > > maven-checkstyle-plugin in
> > > > > >> > >> > their <build> 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
> > > > and
> > > > > >> > >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose
> > > > to 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-1018
> > > > > >> > >> > [4]
> > > > https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > > > > >> > >> > [5] http://checkstyle.sourceforge.net/checks.html
> > > > > >> > >> >
> > > > > >> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> > > > vololo100@gmail.com> 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
> > > > checkstyle
> > > > > >> > >> > > plugin? Is it integrated into IDEA out of box? As I got it
> > > > additional
> > > > > >> > >> > > 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
> > > > visa. Visa
> > > > > >> > >> > > includes result from running inspections job.
> > > > > >> > >> > >
> > > > > >> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> > > > nizhikov@apache.org>:
> > > > > >> > >> > > >
> > > > > >> > >> > > > 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.
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> > > > vololo100@gmail.com>:
> > > > > >> > >> > > >
> > > > > >> > >> > > > > Nikolay,
> > > > > >> > >> > > > >
> > > > > >> > >> > > > > > Should the community spend TC resources for  prototype?
> > > > > >> > >> > > > > Why not? I think it is not bad idea to run all tests
> > > > against 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
> > > > with other
> > > > > >> > >> > > > > Igniters. I think it is the cheapest way to check the
> > > > idea because the
> > > > > >> > >> > > > > check is fully automated. Requiring a human feedback is
> > > > much 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
> > > > skipping tests
> > > > > >> > >> > > > > execution if inspections detect a problem?
> > > > > >> > >> > > > >
> > > > > >> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
> > > > nizhikov@apache.org>:
> > > > > >> > >> > > > > >
> > > > > >> > >> > > > > > 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
> > > > prototype.
> > > > > >> > >> > > > > >
> > > > > >> > >> > > > > > 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?
> > > > > >> > >> > > > > >
> > > > > >> > >> > > > > >
> > > > > >> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
> > > > vololo100@gmail.com>:
> > > > > >> > >> > > > > >
> > > > > >> > >> > > > > > > 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
> > > > outline 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
> > > > that message).
> > > > > >> > >> > > > > > >
> > > > > >> > >> > > > > > > We have a document defining code style which every
> > > > contributor should
> > > > > >> > >> > > > > > > follow [1]. And many points can be checked
> > > > automatically. Personally,
> > > > > >> > >> > > > > > > I do not see much need in writing good javadocs for
> > > > prototype. Why
> > > > > >> > >> > > > > > > should I stub it to be able run any build on TC?
> > > > > >> > >> > > > > > >
> > > > > >> > >> > > > > > > Also, we a have a review process which should be
> > > > applied to every
> > > > > >> > >> > > > > > > patch. Partially it is described in [2]. And due to
> > > > this process every
> > > > > >> > >> > > > > > > patch should not introduce new failures on TC. So,
> > > > the patch should
> > > > > >> > >> > > > > > > not be merged if inspections failed.
> > > > > >> > >> > > > > > >
> > > > > >> > >> > > > > > > P.S. Something more about prototypes and production
> > > > code. There is a
> > > > > >> > >> > > > > > > common bad practice in software engineering. It is
> > > > turning prototypes
> > > > > >> > >> > > > > > > into production code. Often it is much faster to
> > > > create a prototype by
> > > > > >> > >> > > > > > > price of violating some rules of writing "clean
> > > > code". And often
> > > > > >> > >> > > > > > > prototype after successful piloting is turned into
> > > > production code.
> > > > > >> > >> > > > > > > And it is very easy in practice to keep some pieces
> > > > of 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"
> > > > from the beginning.
> > > > > >> > >> > > > > > > So, only ideas are taken from the prototype and a
> > > > code is fully
> > > > > >> > >> > > > > > > rewritten.
> > > > > >> > >> > > > > > >
> > > > > >> > >> > > > > > > [1]
> > > > > >> > >> > > > >
> > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > > >> > >> > > > > > > [2]
> > > > > >> > >> > > > >
> > > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > > >> > >> > > > > > >
> > > > > >> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
> > > > maxmuzaf@gmail.com>:
> > > > > >> > >> > > > > > > >
> > > > > >> > >> > > > > > > > Ivan,
> > > > > >> > >> > > > > > > >
> > > > > >> > >> > > > > > > > As the first implementation of this addition, I'd
> > > > prefer to make it
> > > > > >> > >> > > > > > > > working like _Licenses Headers_ suite check. It
> > > > will fail when some
> > > > > >> > >> > > > > of
> > > > > >> > >> > > > > > > > the code style checks violated. Moreover, these
> > > > licenses header
> > > > > >> > >> > > > > checks
> > > > > >> > >> > > > > > > > can be included in the checkstyle plugin
> > > > configuration.
> > > > > >> > >> > > > > > > >
> > > > > >> > >> > > > > > > > In general, I'd prefer to have a compilation fail
> > > > error with code
> > > > > >> > >> > > > > > > > style checks and after we will get a stable
> > > > checkstyle suite I
> > > > > >> > >> > > > > propose
> > > > > >> > >> > > > > > > > to change it in a "compilation error" way. If we
> > > > are talking about
> > > > > >> > >> > > > > the
> > > > > >> > >> > > > > > > > coding style convenient for most of the community
> > > > members I see no
> > > > > >> > >> > > > > > > > difference with coding sketches or
> > > > production-ready branches equally.
> > > > > >> > >> > > > > > > > Indeed, no one will be against unused imports [or
> > > > spaces 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() == 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 <
> > > > nizhikov@apache.org>
> > > > > >> > >> > > > > > > wrote:
> > > > > >> > >> > > > > > > > >
> > > > > >> > >> > > > > > > > > Actually, I dont see anything wrong with failing
> > > > *compilation*
> > > > > >> > >> > > > > task.
> > > > > >> > >> > > > > > > > >
> > > > > >> > >> > > > > > > > > I think one should use project code style for
> > > > everyday 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?
> > > > > >> > >> > > > > > > > >
> > > > > >> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov
> > > > mr.weider@gmail.com:
> > > > > >> > >> > > > > > > > >
> > > > > >> > >> > > > > > > > > > I guess that was about failing build
> > > > configuration with
> > > > > >> > >> > > > > Checkstype,
> > > > > >> > >> > > > > > > not
> > > > > >> > >> > > > > > > > > > compilation build itself.
> > > > > >> > >> > > > > > > > > >
> > > > > >> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <
> > > > vololo100@gmail.com>
> > > > > >> > >> > > > > > > wrote:
> > > > > >> > >> > > > > > > > > > >
> > > > > >> > >> > > > > > > > > > > Folks,
> > > > > >> > >> > > > > > > > > > >
> > > > > >> > >> > > > > > > > > > > Are you going to fail job compiling Ignite
> > > > sources [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
> > > > convenient to skip some
> > > > > >> > >> > > > > style
> > > > > >> > >> > > > > > > > > > > requirements for such sketches (e.g. well
> > > > formed javadocs).
> > > > > >> > >> > > > > > > > > > >
> > > > > >> > >> > > > > > > > > > > [1]
> > > > > >> > >> > > > > > > > > >
> > > > > >> > >> > > > > > >
> > > > > >> > >> > > > >
> > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > >> > >> > > > > > > > > > >
> > > > > >> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay
> > > > Izhikov <
> > > > > >> > >> > > > > nizhikov@apache.org
> > > > > >> > >> > > > > > > >:
> > > > > >> > >> > > > > > > > > > >>
> > > > > >> > >> > > > > > > > > > >> Petr, we should have 1 configuration for
> > > > project, may be 1
> > > > > >> > >> > > > > > > configuration
> > > > > >> > >> > > > > > > > > > >> per programming language.
> > > > > >> > >> > > > > > > > > > >>
> > > > > >> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
> > > > mr.weider@gmail.com:
> > > > > >> > >> > > > > > > > > > >>
> > > > > >> > >> > > > > > > > > > >>> I was asking about how many build
> > > > configuration is intended?
> > > > > >> > >> > > > > One
> > > > > >> > >> > > > > > > for
> > > > > >> > >> > > > > > > > > > all
> > > > > >> > >> > > > > > > > > > >>> and multiple per module?
> > > > > >> > >> > > > > > > > > > >>>
> > > > > >> > >> > > > > > > > > > >>> With IDEA inspections it was going to be
> > > > build 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
> > > > build task? And each
> > > > > >> > >> > > > > > > module
> > > > > >> > >> > > > > > > > > > builds
> > > > > >> > >> > > > > > > > > > >>>> when it required? If yes, then I propose
> > > > to create a task
> > > > > >> > >> > > > > like
> > > > > >> > >> > > > > > > > > > "Licence
> > > > > >> > >> > > > > > > > > > >>>> check" which will be run for every patch.
> > > > > >> > >> > > > > > > > > > >>>>
> > > > > >> > >> > > > > > > > > > >>>> My point is that violation of codestyle
> > > > should be treated as
> > > > > >> > >> > > > > > > hard as
> > > > > >> > >> > > > > > > > > > >>>> compile error.
> > > > > >> > >> > > > > > > > > > >>>>
> > > > > >> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
> > > > mr.weider@gmail.com
> > > > > >> > >> > > > > :
> > > > > >> > >> > > > > > > > > > >>>>
> > > > > >> > >> > > > > > > > > > >>>>> Is build configuration Inspections
> > > > [Core] meant to
> > > > > >> > >> > > > > transform
> > > > > >> > >> > > > > > > into
> > > > > >> > >> > > > > > > > > > single
> > > > > >> > >> > > > > > > > > > >>>>> all-modules check build configuration
> > > > (without module
> > > > > >> > >> > > > > > > subdivision)?
> > > > > >> > >> > > > > > > > > > >>>>>
> > > > > >> > >> > > > > > > > > > >>>>>
> > > > > >> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay
> > > > Izhikov <
> > > > > >> > >> > > > > > > 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/1065-checkstyle-idea
> > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>> I propose do the following:
> > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > > > >> > >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules.
> > > > Currently, 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
> > > > Apache Ignite"
> > > > > >> > >> > > > > suite.
> > > > > >> > >> > > > > > > Ignite
> > > > > >> > >> > > > > > > > > > has
> > > > > >> > >> > > > > > > > > > >>>>> to
> > > > > >> > >> > > > > > > > > > >>>>>> fail to build if patch violates
> > > > codestyle.
> > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин
> > > > Иван <
> > > > > >> > >> > > > > > > vololo100@gmail.com>:
> > > > > >> > >> > > > > > > > > > >>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>> Hi,
> > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>> I also think that some warning from
> > > > IDEA that some code
> > > > > >> > >> > > > > > > style rule
> > > > > >> > >> > > > > > > > > > is
> > > > > >> > >> > > > > > > > > > >>>>>>> violated is a must-have.
> > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58,
> > > > oignatenko <
> > > > > >> > >> > > > > > > oignatenko@gridgain.com
> > > > > >> > >> > > > > > > > > > >:
> > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
> > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>> I believe that whatever style checks
> > > > we establish at
> > > > > >> > >> > > > > > > Teamcity, we
> > > > > >> > >> > > > > > > > > > >>>>> better
> > > > > >> > >> > > > > > > > > > >>>>>>>> take care of making it easy for
> > > > developers to find and
> > > > > >> > >> > > > > fix
> > > > > >> > >> > > > > > > > > > violations
> > > > > >> > >> > > > > > > > > > >>>>> in
> > > > > >> > >> > > > > > > > > > >>>>>>>> their typical dev environment (for
> > > > Ignite this means, in
> > > > > >> > >> > > > > > > IDEA). I
> > > > > >> > >> > > > > > > > > > >>> think
> > > > > >> > >> > > > > > > > > > >>>>>>> it
> > > > > >> > >> > > > > > > > > > >>>>>>>> is important that developers can
> > > > maintain 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
> > > > just 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
> > > > checkstyle - I
> > > > > >> > >> > > > > recommend
> > > > > >> > >> > > > > > > keeping
> > > > > >> > >> > > > > > > > > > >>> its
> > > > > >> > >> > > > > > > > > > >>>>>>>> config file somewhere in the project
> > > > under version
> > > > > >> > >> > > > > control.
> > > > > >> > >> > > > > > > I
> > > > > >> > >> > > > > > > > > > used to
> > > > > >> > >> > > > > > > > > > >>>>>>>> maintain such a shared style config
> > > > at one of past jobs
> > > > > >> > >> > > > > and
> > > > > >> > >> > > > > > > after
> > > > > >> > >> > > > > > > > > > >>> some
> > > > > >> > >> > > > > > > > > > >>>>>>>> experimenting it turned out most
> > > > convenient to have it
> > > > > >> > >> > > > > this
> > > > > >> > >> > > > > > > way -
> > > > > >> > >> > > > > > > > > > so
> > > > > >> > >> > > > > > > > > > >>>>> that
> > > > > >> > >> > > > > > > > > > >>>>>>>> developers could easily assess and
> > > > discuss style
> > > > > >> > >> > > > > settings
> > > > > >> > >> > > > > > > and keep
> > > > > >> > >> > > > > > > > > > >>>>> track
> > > > > >> > >> > > > > > > > > > >>>>>>> of
> > > > > >> > >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka
> > > > folks 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
> > > > community members.
> > > > > >> > >> > > > > > > Moreover, this
> > > > > >> > >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we
> > > > previously
> > > > > >> > >> > > > > 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
> > > > consider the Apache Kafka
> > > > > >> > >> > > > > > > code
> > > > > >> > >> > > > > > > > > > style
> > > > > >> > >> > > > > > > > > > >>> [5]
> > > > > >> > >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite
> > > > project a
> > > > > >> > >> > > > > > > > > > maven-checkstyle-plugin
> > > > > >> > >> > > > > > > > > > >>>>>>>>> with its own maven profile and run
> > > > it simultaneously
> > > > > >> > >> > > > > with
> > > > > >> > >> > > > > > > other
> > > > > >> > >> > > > > > > > > > TC.
> > > > > >> > >> > > > > > > > > > >>> We
> > > > > >> > >> > > > > > > > > > >>>>>>>>> can also enable the previously
> > > > configured inspection
> > > > > >> > >> > > > > > > rules, so no
> > > > > >> > >> > > > > > > > > > >>>>>>>>> coding style violations will be
> > > > missed.
> > > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>> I see some advantages of using a
> > > > maven plugin:
> > > > > >> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > > > >> > >> > > > > > > > > > >>>>>>>>> - can be used with different CI and
> > > > build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > >> > >> > > > > > > > > > >>>>>>>>> [2]
> > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > >> > >> > > > > > > > > > >>>>>>>>> [3]
> > > > > >> > >> > > > > > > > > > >>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>
> > > > > >> > >> > > > > > > > > > >>>
> > > > > >> > >> > > > > > > > > >
> > > > > >> > >> > > > > > >
> > > > > >> > >> > > > >
> > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > >> > >> > > > > > > > > > >>>>>>>>> [4]
> > > > https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > >> > >> > > > > > > > > > >>>>>>>>> [5]
> > > > > >> > >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr
> > > > Ivanov &lt;
> > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest
> > > > 2018.2 TeamCity
> > > > > >> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>>> [1]
> > > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr
> > > > Ivanov &lt;
> > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy
> > > > Pavlov &lt;
> > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>> dpavlov@
> > > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; 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
> > > > next 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
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > > >
> >
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Code inspection

[Vyacheslav Daradur <da...@gmail.com>]

Maxim,

I looked through the PR and it looks good to me in general.

The only question how it's planned to maintain check styles in 2
different configurations, for IDEA and check style plugin?

On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov <ma...@gmail.com> wrote:
>
> Igniters,
>
> 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).
>
> JIRA: IGNITE-11277 [1]
> PR: [3]
> Upsource: [4]
>
> How can take a look?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-11277
> [2] http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
> [3] https://github.com/apache/ignite/pull/6119
> [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018
>
> On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org> wrote:
> >
> > Hi Igniters,
> >
> > I see that a new TeamCity is released: Version: 2018.2.3.
> >
> > Probably it could solve recently introduced problem related to:
> > Unexpected error during build messages processing in TeamCity;
> >
> > Peter I., could you please check?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> >
> > > 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
> > > today.
> > >
> > > 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.
> > >
> > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > > >
> > > > 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.
> > > >
> > > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
> > > > >
> > > > > +1 to enable code style checks in compile time.
> > > > >
> > > > > We can add option to disable maven codestyle profile with some
> > > environment variable.
> > > > >
> > > > > Anyone who want violate common project rules in their local branch can
> > > set this variable and write some nasty code before push :)
> > > > >
> > > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
> > > > >>
> > > > >> 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
> > > build stage.
> > > > >> - increases a bit the build time procedure
> > > > >> - require additional operations to switch it off for prototyping
> > > branches
> > > > >>
> > > > >> + do not require TC.Bot visa if someone of the community doesn't use
> > > it
> > > > >> + 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
> > > needs.
> > > > >>
> > > > >> ---
> > > > >>
> > > > >> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
> > > 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:
> > > > >> > ====Quoted text====
> > > > >> > 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.
> > > > >> > 2. Style check takes some time. With simple checks it is almost
> > > > >> > negligible. But it can grow if more checks are involved.
> > > > >> > ====End of quoted text====
> > > > >> >
> > > > >> > Some clarifications. 1 is about running from IDEA first. 2 is
> > > related
> > > > >> > to opinions that we should involve much more checks, e.g. using
> > > > >> > abbreviations.
> > > > >> >
> > > > >> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> > > > >> > >
> > > > >> > > Ivan,
> > > > >> > >
> > > > >> > > Let's take a look at all the options we have (ordered by the
> > > frequency 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
> > > checkstyle plugin is used in the <build> 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.
> > > > >> > >
> > > > >> > > Back to our use cases:
> > > > >> > >
> > > > >> > > 1. For checking the ready to merge branches we will fail the
> > > ~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.
> > > > >> > >
> > > > >> > > 2. For the prototyping branches, you can turn off checkstyle in
> > > your 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
> > > checkstyle enabled profile. The common build action as `mvn clean install
> > > -DskipTests` will activate the profile.
> > > > >> > >
> > > > >> > > 4. The checkstyle profile can be disabled explicitly on TC by
> > > specifying -P !checkstyle option. A don't see any use cases of it, but it's
> > > completely doable.
> > > > >> > >
> > > > >> > > Please, correct me if I've missed something.
> > > > >> > >
> > > > >> > > I propose to merge PR [1] as it is, with the configured set of
> > > rules.
> > > > >> > >
> > > > >> > > [1] https://github.com/apache/ignite/pull/6119
> > > > >> > >
> > > > >> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
> > > wrote:
> > > > >> > >>
> > > > >> > >> Maxim,
> > > > >> > >>
> > > > >> > >> I like an idea of being IDE agnostic. I am ok with currently
> > > enabled
> > > > >> > >> 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
> > > 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.
> > > > >> > >> 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"
> > > which I
> > > > >> > >> think is quite useful.
> > > > >> > >>
> > > > >> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
> > > >:
> > > > >> > >> >
> > > > >> > >> > Ivan,
> > > > >> > >> >
> > > > >> > >> > I like that Jetbrains inspections are integrated with IDE and
> > > TC 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
> > > with code
> > > > >> > >> > style checking. I've checked popular java projects: hadoop,
> > > kafka,
> > > > >> > >> > spark, hive, netty. All of them are using
> > > maven-checkstyle-plugin in
> > > > >> > >> > their <build> 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
> > > and
> > > > >> > >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose
> > > to 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-1018
> > > > >> > >> > [4]
> > > https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > > > >> > >> > [5] http://checkstyle.sourceforge.net/checks.html
> > > > >> > >> >
> > > > >> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> > > vololo100@gmail.com> 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
> > > checkstyle
> > > > >> > >> > > plugin? Is it integrated into IDEA out of box? As I got it
> > > additional
> > > > >> > >> > > 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
> > > visa. Visa
> > > > >> > >> > > includes result from running inspections job.
> > > > >> > >> > >
> > > > >> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> > > nizhikov@apache.org>:
> > > > >> > >> > > >
> > > > >> > >> > > > 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.
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> > > vololo100@gmail.com>:
> > > > >> > >> > > >
> > > > >> > >> > > > > Nikolay,
> > > > >> > >> > > > >
> > > > >> > >> > > > > > Should the community spend TC resources for  prototype?
> > > > >> > >> > > > > Why not? I think it is not bad idea to run all tests
> > > against 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
> > > with other
> > > > >> > >> > > > > Igniters. I think it is the cheapest way to check the
> > > idea because the
> > > > >> > >> > > > > check is fully automated. Requiring a human feedback is
> > > much 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
> > > skipping tests
> > > > >> > >> > > > > execution if inspections detect a problem?
> > > > >> > >> > > > >
> > > > >> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
> > > nizhikov@apache.org>:
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > 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
> > > prototype.
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > 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?
> > > > >> > >> > > > > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
> > > vololo100@gmail.com>:
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > > 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
> > > outline 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
> > > that message).
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > We have a document defining code style which every
> > > contributor should
> > > > >> > >> > > > > > > follow [1]. And many points can be checked
> > > automatically. Personally,
> > > > >> > >> > > > > > > I do not see much need in writing good javadocs for
> > > prototype. Why
> > > > >> > >> > > > > > > should I stub it to be able run any build on TC?
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > Also, we a have a review process which should be
> > > applied to every
> > > > >> > >> > > > > > > patch. Partially it is described in [2]. And due to
> > > this process every
> > > > >> > >> > > > > > > patch should not introduce new failures on TC. So,
> > > the patch should
> > > > >> > >> > > > > > > not be merged if inspections failed.
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > P.S. Something more about prototypes and production
> > > code. There is a
> > > > >> > >> > > > > > > common bad practice in software engineering. It is
> > > turning prototypes
> > > > >> > >> > > > > > > into production code. Often it is much faster to
> > > create a prototype by
> > > > >> > >> > > > > > > price of violating some rules of writing "clean
> > > code". And often
> > > > >> > >> > > > > > > prototype after successful piloting is turned into
> > > production code.
> > > > >> > >> > > > > > > And it is very easy in practice to keep some pieces
> > > of 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"
> > > from the beginning.
> > > > >> > >> > > > > > > So, only ideas are taken from the prototype and a
> > > code is fully
> > > > >> > >> > > > > > > rewritten.
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > [1]
> > > > >> > >> > > > >
> > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > >> > >> > > > > > > [2]
> > > > >> > >> > > > >
> > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
> > > maxmuzaf@gmail.com>:
> > > > >> > >> > > > > > > >
> > > > >> > >> > > > > > > > Ivan,
> > > > >> > >> > > > > > > >
> > > > >> > >> > > > > > > > As the first implementation of this addition, I'd
> > > prefer to make it
> > > > >> > >> > > > > > > > working like _Licenses Headers_ suite check. It
> > > will fail when some
> > > > >> > >> > > > > of
> > > > >> > >> > > > > > > > the code style checks violated. Moreover, these
> > > licenses header
> > > > >> > >> > > > > checks
> > > > >> > >> > > > > > > > can be included in the checkstyle plugin
> > > configuration.
> > > > >> > >> > > > > > > >
> > > > >> > >> > > > > > > > In general, I'd prefer to have a compilation fail
> > > error with code
> > > > >> > >> > > > > > > > style checks and after we will get a stable
> > > checkstyle suite I
> > > > >> > >> > > > > propose
> > > > >> > >> > > > > > > > to change it in a "compilation error" way. If we
> > > are talking about
> > > > >> > >> > > > > the
> > > > >> > >> > > > > > > > coding style convenient for most of the community
> > > members I see no
> > > > >> > >> > > > > > > > difference with coding sketches or
> > > production-ready branches equally.
> > > > >> > >> > > > > > > > Indeed, no one will be against unused imports [or
> > > spaces 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() == 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 <
> > > nizhikov@apache.org>
> > > > >> > >> > > > > > > wrote:
> > > > >> > >> > > > > > > > >
> > > > >> > >> > > > > > > > > Actually, I dont see anything wrong with failing
> > > *compilation*
> > > > >> > >> > > > > task.
> > > > >> > >> > > > > > > > >
> > > > >> > >> > > > > > > > > I think one should use project code style for
> > > everyday 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?
> > > > >> > >> > > > > > > > >
> > > > >> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov
> > > mr.weider@gmail.com:
> > > > >> > >> > > > > > > > >
> > > > >> > >> > > > > > > > > > I guess that was about failing build
> > > configuration with
> > > > >> > >> > > > > Checkstype,
> > > > >> > >> > > > > > > not
> > > > >> > >> > > > > > > > > > compilation build itself.
> > > > >> > >> > > > > > > > > >
> > > > >> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <
> > > vololo100@gmail.com>
> > > > >> > >> > > > > > > wrote:
> > > > >> > >> > > > > > > > > > >
> > > > >> > >> > > > > > > > > > > Folks,
> > > > >> > >> > > > > > > > > > >
> > > > >> > >> > > > > > > > > > > Are you going to fail job compiling Ignite
> > > sources [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
> > > convenient to skip some
> > > > >> > >> > > > > style
> > > > >> > >> > > > > > > > > > > requirements for such sketches (e.g. well
> > > formed javadocs).
> > > > >> > >> > > > > > > > > > >
> > > > >> > >> > > > > > > > > > > [1]
> > > > >> > >> > > > > > > > > >
> > > > >> > >> > > > > > >
> > > > >> > >> > > > >
> > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > >> > >> > > > > > > > > > >
> > > > >> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay
> > > Izhikov <
> > > > >> > >> > > > > nizhikov@apache.org
> > > > >> > >> > > > > > > >:
> > > > >> > >> > > > > > > > > > >>
> > > > >> > >> > > > > > > > > > >> Petr, we should have 1 configuration for
> > > project, may be 1
> > > > >> > >> > > > > > > configuration
> > > > >> > >> > > > > > > > > > >> per programming language.
> > > > >> > >> > > > > > > > > > >>
> > > > >> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
> > > mr.weider@gmail.com:
> > > > >> > >> > > > > > > > > > >>
> > > > >> > >> > > > > > > > > > >>> I was asking about how many build
> > > configuration is intended?
> > > > >> > >> > > > > One
> > > > >> > >> > > > > > > for
> > > > >> > >> > > > > > > > > > all
> > > > >> > >> > > > > > > > > > >>> and multiple per module?
> > > > >> > >> > > > > > > > > > >>>
> > > > >> > >> > > > > > > > > > >>> With IDEA inspections it was going to be
> > > build 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
> > > build task? And each
> > > > >> > >> > > > > > > module
> > > > >> > >> > > > > > > > > > builds
> > > > >> > >> > > > > > > > > > >>>> when it required? If yes, then I propose
> > > to create a task
> > > > >> > >> > > > > like
> > > > >> > >> > > > > > > > > > "Licence
> > > > >> > >> > > > > > > > > > >>>> check" which will be run for every patch.
> > > > >> > >> > > > > > > > > > >>>>
> > > > >> > >> > > > > > > > > > >>>> My point is that violation of codestyle
> > > should be treated as
> > > > >> > >> > > > > > > hard as
> > > > >> > >> > > > > > > > > > >>>> compile error.
> > > > >> > >> > > > > > > > > > >>>>
> > > > >> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
> > > mr.weider@gmail.com
> > > > >> > >> > > > > :
> > > > >> > >> > > > > > > > > > >>>>
> > > > >> > >> > > > > > > > > > >>>>> Is build configuration Inspections
> > > [Core] meant to
> > > > >> > >> > > > > transform
> > > > >> > >> > > > > > > into
> > > > >> > >> > > > > > > > > > single
> > > > >> > >> > > > > > > > > > >>>>> all-modules check build configuration
> > > (without module
> > > > >> > >> > > > > > > subdivision)?
> > > > >> > >> > > > > > > > > > >>>>>
> > > > >> > >> > > > > > > > > > >>>>>
> > > > >> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay
> > > Izhikov <
> > > > >> > >> > > > > > > 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/1065-checkstyle-idea
> > > > >> > >> > > > > > > > > > >>>>>>
> > > > >> > >> > > > > > > > > > >>>>>> I propose do the following:
> > > > >> > >> > > > > > > > > > >>>>>>
> > > > >> > >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > > >> > >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules.
> > > Currently, 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
> > > Apache Ignite"
> > > > >> > >> > > > > suite.
> > > > >> > >> > > > > > > Ignite
> > > > >> > >> > > > > > > > > > has
> > > > >> > >> > > > > > > > > > >>>>> to
> > > > >> > >> > > > > > > > > > >>>>>> fail to build if patch violates
> > > codestyle.
> > > > >> > >> > > > > > > > > > >>>>>>
> > > > >> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин
> > > Иван <
> > > > >> > >> > > > > > > vololo100@gmail.com>:
> > > > >> > >> > > > > > > > > > >>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>> Hi,
> > > > >> > >> > > > > > > > > > >>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>> I also think that some warning from
> > > IDEA that some code
> > > > >> > >> > > > > > > style rule
> > > > >> > >> > > > > > > > > > is
> > > > >> > >> > > > > > > > > > >>>>>>> violated is a must-have.
> > > > >> > >> > > > > > > > > > >>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58,
> > > oignatenko <
> > > > >> > >> > > > > > > oignatenko@gridgain.com
> > > > >> > >> > > > > > > > > > >:
> > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
> > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>> I believe that whatever style checks
> > > we establish at
> > > > >> > >> > > > > > > Teamcity, we
> > > > >> > >> > > > > > > > > > >>>>> better
> > > > >> > >> > > > > > > > > > >>>>>>>> take care of making it easy for
> > > developers to find and
> > > > >> > >> > > > > fix
> > > > >> > >> > > > > > > > > > violations
> > > > >> > >> > > > > > > > > > >>>>> in
> > > > >> > >> > > > > > > > > > >>>>>>>> their typical dev environment (for
> > > Ignite this means, in
> > > > >> > >> > > > > > > IDEA). I
> > > > >> > >> > > > > > > > > > >>> think
> > > > >> > >> > > > > > > > > > >>>>>>> it
> > > > >> > >> > > > > > > > > > >>>>>>>> is important that developers can
> > > maintain 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
> > > just 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
> > > checkstyle - I
> > > > >> > >> > > > > recommend
> > > > >> > >> > > > > > > keeping
> > > > >> > >> > > > > > > > > > >>> its
> > > > >> > >> > > > > > > > > > >>>>>>>> config file somewhere in the project
> > > under version
> > > > >> > >> > > > > control.
> > > > >> > >> > > > > > > I
> > > > >> > >> > > > > > > > > > used to
> > > > >> > >> > > > > > > > > > >>>>>>>> maintain such a shared style config
> > > at one of past jobs
> > > > >> > >> > > > > and
> > > > >> > >> > > > > > > after
> > > > >> > >> > > > > > > > > > >>> some
> > > > >> > >> > > > > > > > > > >>>>>>>> experimenting it turned out most
> > > convenient to have it
> > > > >> > >> > > > > this
> > > > >> > >> > > > > > > way -
> > > > >> > >> > > > > > > > > > so
> > > > >> > >> > > > > > > > > > >>>>> that
> > > > >> > >> > > > > > > > > > >>>>>>>> developers could easily assess and
> > > discuss style
> > > > >> > >> > > > > settings
> > > > >> > >> > > > > > > and keep
> > > > >> > >> > > > > > > > > > >>>>> track
> > > > >> > >> > > > > > > > > > >>>>>>> of
> > > > >> > >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka
> > > folks 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
> > > community members.
> > > > >> > >> > > > > > > Moreover, this
> > > > >> > >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we
> > > previously
> > > > >> > >> > > > > 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
> > > consider the Apache Kafka
> > > > >> > >> > > > > > > code
> > > > >> > >> > > > > > > > > > style
> > > > >> > >> > > > > > > > > > >>> [5]
> > > > >> > >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite
> > > project a
> > > > >> > >> > > > > > > > > > maven-checkstyle-plugin
> > > > >> > >> > > > > > > > > > >>>>>>>>> with its own maven profile and run
> > > it simultaneously
> > > > >> > >> > > > > with
> > > > >> > >> > > > > > > other
> > > > >> > >> > > > > > > > > > TC.
> > > > >> > >> > > > > > > > > > >>> We
> > > > >> > >> > > > > > > > > > >>>>>>>>> can also enable the previously
> > > configured inspection
> > > > >> > >> > > > > > > rules, so no
> > > > >> > >> > > > > > > > > > >>>>>>>>> coding style violations will be
> > > missed.
> > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>> I see some advantages of using a
> > > maven plugin:
> > > > >> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > > >> > >> > > > > > > > > > >>>>>>>>> - can be used with different CI and
> > > build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > >> > >> > > > > > > > > > >>>>>>>>> [2]
> > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > >> > >> > > > > > > > > > >>>>>>>>> [3]
> > > > >> > >> > > > > > > > > > >>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>
> > > > >> > >> > > > > > > > > > >>>
> > > > >> > >> > > > > > > > > >
> > > > >> > >> > > > > > >
> > > > >> > >> > > > >
> > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > >> > >> > > > > > > > > > >>>>>>>>> [4]
> > > https://issues.apache.org/jira/browse/IGNITE-11277
> > > > >> > >> > > > > > > > > > >>>>>>>>> [5]
> > > > >> > >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > >> > >> > > > > > > > > > >>>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr
> > > Ivanov &lt;
> > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest
> > > 2018.2 TeamCity
> > > > >> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>>> [1]
> > > https://youtrack.jetbrains.com/issue/TW-58504
> > > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr
> > > Ivanov &lt;
> > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy
> > > Pavlov &lt;
> > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>> dpavlov@
> > > > >> > >> > > > > > > > > > >>>>>>>>
> > > > >> > >> > > > > > > > > > >>>>>>>>> &gt; 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
> > > next 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
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> > >
>


-- 
Best Regards, Vyacheslav D.

Re: Code inspection

[Maxim Muzafarov <ma...@gmail.com>]

Igniters,

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).

JIRA: IGNITE-11277 [1]
PR: [3]
Upsource: [4]

How can take a look?

[1] https://issues.apache.org/jira/browse/IGNITE-11277
[2] http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html
[3] https://github.com/apache/ignite/pull/6119
[4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018

On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov <dp...@apache.org> wrote:
>
> Hi Igniters,
>
> I see that a new TeamCity is released: Version: 2018.2.3.
>
> Probably it could solve recently introduced problem related to:
> Unexpected error during build messages processing in TeamCity;
>
> Peter I., could you please check?
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
>
> > 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
> > today.
> >
> > 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.
> >
> > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > >
> > > 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.
> > >
> > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
> > > >
> > > > +1 to enable code style checks in compile time.
> > > >
> > > > We can add option to disable maven codestyle profile with some
> > environment variable.
> > > >
> > > > Anyone who want violate common project rules in their local branch can
> > set this variable and write some nasty code before push :)
> > > >
> > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
> > > >>
> > > >> 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
> > build stage.
> > > >> - increases a bit the build time procedure
> > > >> - require additional operations to switch it off for prototyping
> > branches
> > > >>
> > > >> + do not require TC.Bot visa if someone of the community doesn't use
> > it
> > > >> + 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
> > needs.
> > > >>
> > > >> ---
> > > >>
> > > >> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
> > 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:
> > > >> > ====Quoted text====
> > > >> > 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.
> > > >> > 2. Style check takes some time. With simple checks it is almost
> > > >> > negligible. But it can grow if more checks are involved.
> > > >> > ====End of quoted text====
> > > >> >
> > > >> > Some clarifications. 1 is about running from IDEA first. 2 is
> > related
> > > >> > to opinions that we should involve much more checks, e.g. using
> > > >> > abbreviations.
> > > >> >
> > > >> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> > > >> > >
> > > >> > > Ivan,
> > > >> > >
> > > >> > > Let's take a look at all the options we have (ordered by the
> > frequency 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
> > checkstyle plugin is used in the <build> 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.
> > > >> > >
> > > >> > > Back to our use cases:
> > > >> > >
> > > >> > > 1. For checking the ready to merge branches we will fail the
> > ~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.
> > > >> > >
> > > >> > > 2. For the prototyping branches, you can turn off checkstyle in
> > your 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
> > checkstyle enabled profile. The common build action as `mvn clean install
> > -DskipTests` will activate the profile.
> > > >> > >
> > > >> > > 4. The checkstyle profile can be disabled explicitly on TC by
> > specifying -P !checkstyle option. A don't see any use cases of it, but it's
> > completely doable.
> > > >> > >
> > > >> > > Please, correct me if I've missed something.
> > > >> > >
> > > >> > > I propose to merge PR [1] as it is, with the configured set of
> > rules.
> > > >> > >
> > > >> > > [1] https://github.com/apache/ignite/pull/6119
> > > >> > >
> > > >> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
> > wrote:
> > > >> > >>
> > > >> > >> Maxim,
> > > >> > >>
> > > >> > >> I like an idea of being IDE agnostic. I am ok with currently
> > enabled
> > > >> > >> 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
> > 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.
> > > >> > >> 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"
> > which I
> > > >> > >> think is quite useful.
> > > >> > >>
> > > >> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
> > >:
> > > >> > >> >
> > > >> > >> > Ivan,
> > > >> > >> >
> > > >> > >> > I like that Jetbrains inspections are integrated with IDE and
> > TC 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
> > with code
> > > >> > >> > style checking. I've checked popular java projects: hadoop,
> > kafka,
> > > >> > >> > spark, hive, netty. All of them are using
> > maven-checkstyle-plugin in
> > > >> > >> > their <build> 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
> > and
> > > >> > >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose
> > to 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-1018
> > > >> > >> > [4]
> > https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > > >> > >> > [5] http://checkstyle.sourceforge.net/checks.html
> > > >> > >> >
> > > >> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> > vololo100@gmail.com> 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
> > checkstyle
> > > >> > >> > > plugin? Is it integrated into IDEA out of box? As I got it
> > additional
> > > >> > >> > > 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
> > visa. Visa
> > > >> > >> > > includes result from running inspections job.
> > > >> > >> > >
> > > >> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> > nizhikov@apache.org>:
> > > >> > >> > > >
> > > >> > >> > > > 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.
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> > vololo100@gmail.com>:
> > > >> > >> > > >
> > > >> > >> > > > > Nikolay,
> > > >> > >> > > > >
> > > >> > >> > > > > > Should the community spend TC resources for  prototype?
> > > >> > >> > > > > Why not? I think it is not bad idea to run all tests
> > against 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
> > with other
> > > >> > >> > > > > Igniters. I think it is the cheapest way to check the
> > idea because the
> > > >> > >> > > > > check is fully automated. Requiring a human feedback is
> > much 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
> > skipping tests
> > > >> > >> > > > > execution if inspections detect a problem?
> > > >> > >> > > > >
> > > >> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
> > nizhikov@apache.org>:
> > > >> > >> > > > > >
> > > >> > >> > > > > > 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
> > prototype.
> > > >> > >> > > > > >
> > > >> > >> > > > > > 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?
> > > >> > >> > > > > >
> > > >> > >> > > > > >
> > > >> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
> > vololo100@gmail.com>:
> > > >> > >> > > > > >
> > > >> > >> > > > > > > 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
> > outline 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
> > that message).
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > We have a document defining code style which every
> > contributor should
> > > >> > >> > > > > > > follow [1]. And many points can be checked
> > automatically. Personally,
> > > >> > >> > > > > > > I do not see much need in writing good javadocs for
> > prototype. Why
> > > >> > >> > > > > > > should I stub it to be able run any build on TC?
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > Also, we a have a review process which should be
> > applied to every
> > > >> > >> > > > > > > patch. Partially it is described in [2]. And due to
> > this process every
> > > >> > >> > > > > > > patch should not introduce new failures on TC. So,
> > the patch should
> > > >> > >> > > > > > > not be merged if inspections failed.
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > P.S. Something more about prototypes and production
> > code. There is a
> > > >> > >> > > > > > > common bad practice in software engineering. It is
> > turning prototypes
> > > >> > >> > > > > > > into production code. Often it is much faster to
> > create a prototype by
> > > >> > >> > > > > > > price of violating some rules of writing "clean
> > code". And often
> > > >> > >> > > > > > > prototype after successful piloting is turned into
> > production code.
> > > >> > >> > > > > > > And it is very easy in practice to keep some pieces
> > of 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"
> > from the beginning.
> > > >> > >> > > > > > > So, only ideas are taken from the prototype and a
> > code is fully
> > > >> > >> > > > > > > rewritten.
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > [1]
> > > >> > >> > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > >> > >> > > > > > > [2]
> > > >> > >> > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
> > maxmuzaf@gmail.com>:
> > > >> > >> > > > > > > >
> > > >> > >> > > > > > > > Ivan,
> > > >> > >> > > > > > > >
> > > >> > >> > > > > > > > As the first implementation of this addition, I'd
> > prefer to make it
> > > >> > >> > > > > > > > working like _Licenses Headers_ suite check. It
> > will fail when some
> > > >> > >> > > > > of
> > > >> > >> > > > > > > > the code style checks violated. Moreover, these
> > licenses header
> > > >> > >> > > > > checks
> > > >> > >> > > > > > > > can be included in the checkstyle plugin
> > configuration.
> > > >> > >> > > > > > > >
> > > >> > >> > > > > > > > In general, I'd prefer to have a compilation fail
> > error with code
> > > >> > >> > > > > > > > style checks and after we will get a stable
> > checkstyle suite I
> > > >> > >> > > > > propose
> > > >> > >> > > > > > > > to change it in a "compilation error" way. If we
> > are talking about
> > > >> > >> > > > > the
> > > >> > >> > > > > > > > coding style convenient for most of the community
> > members I see no
> > > >> > >> > > > > > > > difference with coding sketches or
> > production-ready branches equally.
> > > >> > >> > > > > > > > Indeed, no one will be against unused imports [or
> > spaces 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() == 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 <
> > nizhikov@apache.org>
> > > >> > >> > > > > > > wrote:
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > > Actually, I dont see anything wrong with failing
> > *compilation*
> > > >> > >> > > > > task.
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > > I think one should use project code style for
> > everyday 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?
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov
> > mr.weider@gmail.com:
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > > > I guess that was about failing build
> > configuration with
> > > >> > >> > > > > Checkstype,
> > > >> > >> > > > > > > not
> > > >> > >> > > > > > > > > > compilation build itself.
> > > >> > >> > > > > > > > > >
> > > >> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <
> > vololo100@gmail.com>
> > > >> > >> > > > > > > wrote:
> > > >> > >> > > > > > > > > > >
> > > >> > >> > > > > > > > > > > Folks,
> > > >> > >> > > > > > > > > > >
> > > >> > >> > > > > > > > > > > Are you going to fail job compiling Ignite
> > sources [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
> > convenient to skip some
> > > >> > >> > > > > style
> > > >> > >> > > > > > > > > > > requirements for such sketches (e.g. well
> > formed javadocs).
> > > >> > >> > > > > > > > > > >
> > > >> > >> > > > > > > > > > > [1]
> > > >> > >> > > > > > > > > >
> > > >> > >> > > > > > >
> > > >> > >> > > > >
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > >> > >> > > > > > > > > > >
> > > >> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay
> > Izhikov <
> > > >> > >> > > > > nizhikov@apache.org
> > > >> > >> > > > > > > >:
> > > >> > >> > > > > > > > > > >>
> > > >> > >> > > > > > > > > > >> Petr, we should have 1 configuration for
> > project, may be 1
> > > >> > >> > > > > > > configuration
> > > >> > >> > > > > > > > > > >> per programming language.
> > > >> > >> > > > > > > > > > >>
> > > >> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
> > mr.weider@gmail.com:
> > > >> > >> > > > > > > > > > >>
> > > >> > >> > > > > > > > > > >>> I was asking about how many build
> > configuration is intended?
> > > >> > >> > > > > One
> > > >> > >> > > > > > > for
> > > >> > >> > > > > > > > > > all
> > > >> > >> > > > > > > > > > >>> and multiple per module?
> > > >> > >> > > > > > > > > > >>>
> > > >> > >> > > > > > > > > > >>> With IDEA inspections it was going to be
> > build 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
> > build task? And each
> > > >> > >> > > > > > > module
> > > >> > >> > > > > > > > > > builds
> > > >> > >> > > > > > > > > > >>>> when it required? If yes, then I propose
> > to create a task
> > > >> > >> > > > > like
> > > >> > >> > > > > > > > > > "Licence
> > > >> > >> > > > > > > > > > >>>> check" which will be run for every patch.
> > > >> > >> > > > > > > > > > >>>>
> > > >> > >> > > > > > > > > > >>>> My point is that violation of codestyle
> > should be treated as
> > > >> > >> > > > > > > hard as
> > > >> > >> > > > > > > > > > >>>> compile error.
> > > >> > >> > > > > > > > > > >>>>
> > > >> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
> > mr.weider@gmail.com
> > > >> > >> > > > > :
> > > >> > >> > > > > > > > > > >>>>
> > > >> > >> > > > > > > > > > >>>>> Is build configuration Inspections
> > [Core] meant to
> > > >> > >> > > > > transform
> > > >> > >> > > > > > > into
> > > >> > >> > > > > > > > > > single
> > > >> > >> > > > > > > > > > >>>>> all-modules check build configuration
> > (without module
> > > >> > >> > > > > > > subdivision)?
> > > >> > >> > > > > > > > > > >>>>>
> > > >> > >> > > > > > > > > > >>>>>
> > > >> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay
> > Izhikov <
> > > >> > >> > > > > > > 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/1065-checkstyle-idea
> > > >> > >> > > > > > > > > > >>>>>>
> > > >> > >> > > > > > > > > > >>>>>> I propose do the following:
> > > >> > >> > > > > > > > > > >>>>>>
> > > >> > >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > >> > >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules.
> > Currently, 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
> > Apache Ignite"
> > > >> > >> > > > > suite.
> > > >> > >> > > > > > > Ignite
> > > >> > >> > > > > > > > > > has
> > > >> > >> > > > > > > > > > >>>>> to
> > > >> > >> > > > > > > > > > >>>>>> fail to build if patch violates
> > codestyle.
> > > >> > >> > > > > > > > > > >>>>>>
> > > >> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин
> > Иван <
> > > >> > >> > > > > > > vololo100@gmail.com>:
> > > >> > >> > > > > > > > > > >>>>>>
> > > >> > >> > > > > > > > > > >>>>>>> Hi,
> > > >> > >> > > > > > > > > > >>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>> I also think that some warning from
> > IDEA that some code
> > > >> > >> > > > > > > style rule
> > > >> > >> > > > > > > > > > is
> > > >> > >> > > > > > > > > > >>>>>>> violated is a must-have.
> > > >> > >> > > > > > > > > > >>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58,
> > oignatenko <
> > > >> > >> > > > > > > oignatenko@gridgain.com
> > > >> > >> > > > > > > > > > >:
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>> I believe that whatever style checks
> > we establish at
> > > >> > >> > > > > > > Teamcity, we
> > > >> > >> > > > > > > > > > >>>>> better
> > > >> > >> > > > > > > > > > >>>>>>>> take care of making it easy for
> > developers to find and
> > > >> > >> > > > > fix
> > > >> > >> > > > > > > > > > violations
> > > >> > >> > > > > > > > > > >>>>> in
> > > >> > >> > > > > > > > > > >>>>>>>> their typical dev environment (for
> > Ignite this means, in
> > > >> > >> > > > > > > IDEA). I
> > > >> > >> > > > > > > > > > >>> think
> > > >> > >> > > > > > > > > > >>>>>>> it
> > > >> > >> > > > > > > > > > >>>>>>>> is important that developers can
> > maintain 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
> > just 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
> > checkstyle - I
> > > >> > >> > > > > recommend
> > > >> > >> > > > > > > keeping
> > > >> > >> > > > > > > > > > >>> its
> > > >> > >> > > > > > > > > > >>>>>>>> config file somewhere in the project
> > under version
> > > >> > >> > > > > control.
> > > >> > >> > > > > > > I
> > > >> > >> > > > > > > > > > used to
> > > >> > >> > > > > > > > > > >>>>>>>> maintain such a shared style config
> > at one of past jobs
> > > >> > >> > > > > and
> > > >> > >> > > > > > > after
> > > >> > >> > > > > > > > > > >>> some
> > > >> > >> > > > > > > > > > >>>>>>>> experimenting it turned out most
> > convenient to have it
> > > >> > >> > > > > this
> > > >> > >> > > > > > > way -
> > > >> > >> > > > > > > > > > so
> > > >> > >> > > > > > > > > > >>>>> that
> > > >> > >> > > > > > > > > > >>>>>>>> developers could easily assess and
> > discuss style
> > > >> > >> > > > > settings
> > > >> > >> > > > > > > and keep
> > > >> > >> > > > > > > > > > >>>>> track
> > > >> > >> > > > > > > > > > >>>>>>> of
> > > >> > >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka
> > folks 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
> > community members.
> > > >> > >> > > > > > > Moreover, this
> > > >> > >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we
> > previously
> > > >> > >> > > > > 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
> > consider the Apache Kafka
> > > >> > >> > > > > > > code
> > > >> > >> > > > > > > > > > style
> > > >> > >> > > > > > > > > > >>> [5]
> > > >> > >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite
> > project a
> > > >> > >> > > > > > > > > > maven-checkstyle-plugin
> > > >> > >> > > > > > > > > > >>>>>>>>> with its own maven profile and run
> > it simultaneously
> > > >> > >> > > > > with
> > > >> > >> > > > > > > other
> > > >> > >> > > > > > > > > > TC.
> > > >> > >> > > > > > > > > > >>> We
> > > >> > >> > > > > > > > > > >>>>>>>>> can also enable the previously
> > configured inspection
> > > >> > >> > > > > > > rules, so no
> > > >> > >> > > > > > > > > > >>>>>>>>> coding style violations will be
> > missed.
> > > >> > >> > > > > > > > > > >>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> I see some advantages of using a
> > maven plugin:
> > > >> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > >> > >> > > > > > > > > > >>>>>>>>> - can be used with different CI and
> > build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > >> > >> > > > > > > > > > >>>>>>>>> [2]
> > https://youtrack.jetbrains.com/issue/TW-58504
> > > >> > >> > > > > > > > > > >>>>>>>>> [3]
> > > >> > >> > > > > > > > > > >>>>>>>
> > > >> > >> > > > > > > > > > >>>>>
> > > >> > >> > > > > > > > > > >>>
> > > >> > >> > > > > > > > > >
> > > >> > >> > > > > > >
> > > >> > >> > > > >
> > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > >> > >> > > > > > > > > > >>>>>>>>> [4]
> > https://issues.apache.org/jira/browse/IGNITE-11277
> > > >> > >> > > > > > > > > > >>>>>>>>> [5]
> > > >> > >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > >> > >> > > > > > > > > > >>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr
> > Ivanov &lt;
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest
> > 2018.2 TeamCity
> > > >> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>> [1]
> > https://youtrack.jetbrains.com/issue/TW-58504
> > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr
> > Ivanov &lt;
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy
> > Pavlov &lt;
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> dpavlov@
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> &gt; 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
> > next 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
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
> >

Re: Code inspection

[Павлухин Иван <vo...@gmail.com>]

Dmitriy,

Benefits of using maven checkstyle plugin against IDEA-TC integration
were discussed above. IMHO there is a one crucial thing. IDEA-TC
integeration have been broken for a months without any good reason. We
cannot be sure that the same will not repeat again.

пт, 15 мар. 2019 г. в 19:19, Dmitriy Pavlov <dp...@apache.org>:
>
> Hi Igniters,
>
> I see that a new TeamCity is released: Version: 2018.2.3.
>
> Probably it could solve recently introduced problem related to:
> Unexpected error during build messages processing in TeamCity;
>
> Peter I., could you please check?
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
>
> > 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
> > today.
> >
> > 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.
> >
> > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> > >
> > > 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.
> > >
> > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
> > > >
> > > > +1 to enable code style checks in compile time.
> > > >
> > > > We can add option to disable maven codestyle profile with some
> > environment variable.
> > > >
> > > > Anyone who want violate common project rules in their local branch can
> > set this variable and write some nasty code before push :)
> > > >
> > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
> > > >>
> > > >> 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
> > build stage.
> > > >> - increases a bit the build time procedure
> > > >> - require additional operations to switch it off for prototyping
> > branches
> > > >>
> > > >> + do not require TC.Bot visa if someone of the community doesn't use
> > it
> > > >> + 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
> > needs.
> > > >>
> > > >> ---
> > > >>
> > > >> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
> > 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:
> > > >> > ====Quoted text====
> > > >> > 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.
> > > >> > 2. Style check takes some time. With simple checks it is almost
> > > >> > negligible. But it can grow if more checks are involved.
> > > >> > ====End of quoted text====
> > > >> >
> > > >> > Some clarifications. 1 is about running from IDEA first. 2 is
> > related
> > > >> > to opinions that we should involve much more checks, e.g. using
> > > >> > abbreviations.
> > > >> >
> > > >> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> > > >> > >
> > > >> > > Ivan,
> > > >> > >
> > > >> > > Let's take a look at all the options we have (ordered by the
> > frequency 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
> > checkstyle plugin is used in the <build> 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.
> > > >> > >
> > > >> > > Back to our use cases:
> > > >> > >
> > > >> > > 1. For checking the ready to merge branches we will fail the
> > ~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.
> > > >> > >
> > > >> > > 2. For the prototyping branches, you can turn off checkstyle in
> > your 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
> > checkstyle enabled profile. The common build action as `mvn clean install
> > -DskipTests` will activate the profile.
> > > >> > >
> > > >> > > 4. The checkstyle profile can be disabled explicitly on TC by
> > specifying -P !checkstyle option. A don't see any use cases of it, but it's
> > completely doable.
> > > >> > >
> > > >> > > Please, correct me if I've missed something.
> > > >> > >
> > > >> > > I propose to merge PR [1] as it is, with the configured set of
> > rules.
> > > >> > >
> > > >> > > [1] https://github.com/apache/ignite/pull/6119
> > > >> > >
> > > >> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
> > wrote:
> > > >> > >>
> > > >> > >> Maxim,
> > > >> > >>
> > > >> > >> I like an idea of being IDE agnostic. I am ok with currently
> > enabled
> > > >> > >> 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
> > 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.
> > > >> > >> 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"
> > which I
> > > >> > >> think is quite useful.
> > > >> > >>
> > > >> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
> > >:
> > > >> > >> >
> > > >> > >> > Ivan,
> > > >> > >> >
> > > >> > >> > I like that Jetbrains inspections are integrated with IDE and
> > TC 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
> > with code
> > > >> > >> > style checking. I've checked popular java projects: hadoop,
> > kafka,
> > > >> > >> > spark, hive, netty. All of them are using
> > maven-checkstyle-plugin in
> > > >> > >> > their <build> 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
> > and
> > > >> > >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose
> > to 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-1018
> > > >> > >> > [4]
> > https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > > >> > >> > [5] http://checkstyle.sourceforge.net/checks.html
> > > >> > >> >
> > > >> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> > vololo100@gmail.com> 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
> > checkstyle
> > > >> > >> > > plugin? Is it integrated into IDEA out of box? As I got it
> > additional
> > > >> > >> > > 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
> > visa. Visa
> > > >> > >> > > includes result from running inspections job.
> > > >> > >> > >
> > > >> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> > nizhikov@apache.org>:
> > > >> > >> > > >
> > > >> > >> > > > 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.
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> > vololo100@gmail.com>:
> > > >> > >> > > >
> > > >> > >> > > > > Nikolay,
> > > >> > >> > > > >
> > > >> > >> > > > > > Should the community spend TC resources for  prototype?
> > > >> > >> > > > > Why not? I think it is not bad idea to run all tests
> > against 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
> > with other
> > > >> > >> > > > > Igniters. I think it is the cheapest way to check the
> > idea because the
> > > >> > >> > > > > check is fully automated. Requiring a human feedback is
> > much 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
> > skipping tests
> > > >> > >> > > > > execution if inspections detect a problem?
> > > >> > >> > > > >
> > > >> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
> > nizhikov@apache.org>:
> > > >> > >> > > > > >
> > > >> > >> > > > > > 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
> > prototype.
> > > >> > >> > > > > >
> > > >> > >> > > > > > 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?
> > > >> > >> > > > > >
> > > >> > >> > > > > >
> > > >> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
> > vololo100@gmail.com>:
> > > >> > >> > > > > >
> > > >> > >> > > > > > > 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
> > outline 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
> > that message).
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > We have a document defining code style which every
> > contributor should
> > > >> > >> > > > > > > follow [1]. And many points can be checked
> > automatically. Personally,
> > > >> > >> > > > > > > I do not see much need in writing good javadocs for
> > prototype. Why
> > > >> > >> > > > > > > should I stub it to be able run any build on TC?
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > Also, we a have a review process which should be
> > applied to every
> > > >> > >> > > > > > > patch. Partially it is described in [2]. And due to
> > this process every
> > > >> > >> > > > > > > patch should not introduce new failures on TC. So,
> > the patch should
> > > >> > >> > > > > > > not be merged if inspections failed.
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > P.S. Something more about prototypes and production
> > code. There is a
> > > >> > >> > > > > > > common bad practice in software engineering. It is
> > turning prototypes
> > > >> > >> > > > > > > into production code. Often it is much faster to
> > create a prototype by
> > > >> > >> > > > > > > price of violating some rules of writing "clean
> > code". And often
> > > >> > >> > > > > > > prototype after successful piloting is turned into
> > production code.
> > > >> > >> > > > > > > And it is very easy in practice to keep some pieces
> > of 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"
> > from the beginning.
> > > >> > >> > > > > > > So, only ideas are taken from the prototype and a
> > code is fully
> > > >> > >> > > > > > > rewritten.
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > [1]
> > > >> > >> > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > >> > >> > > > > > > [2]
> > > >> > >> > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
> > maxmuzaf@gmail.com>:
> > > >> > >> > > > > > > >
> > > >> > >> > > > > > > > Ivan,
> > > >> > >> > > > > > > >
> > > >> > >> > > > > > > > As the first implementation of this addition, I'd
> > prefer to make it
> > > >> > >> > > > > > > > working like _Licenses Headers_ suite check. It
> > will fail when some
> > > >> > >> > > > > of
> > > >> > >> > > > > > > > the code style checks violated. Moreover, these
> > licenses header
> > > >> > >> > > > > checks
> > > >> > >> > > > > > > > can be included in the checkstyle plugin
> > configuration.
> > > >> > >> > > > > > > >
> > > >> > >> > > > > > > > In general, I'd prefer to have a compilation fail
> > error with code
> > > >> > >> > > > > > > > style checks and after we will get a stable
> > checkstyle suite I
> > > >> > >> > > > > propose
> > > >> > >> > > > > > > > to change it in a "compilation error" way. If we
> > are talking about
> > > >> > >> > > > > the
> > > >> > >> > > > > > > > coding style convenient for most of the community
> > members I see no
> > > >> > >> > > > > > > > difference with coding sketches or
> > production-ready branches equally.
> > > >> > >> > > > > > > > Indeed, no one will be against unused imports [or
> > spaces 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() == 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 <
> > nizhikov@apache.org>
> > > >> > >> > > > > > > wrote:
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > > Actually, I dont see anything wrong with failing
> > *compilation*
> > > >> > >> > > > > task.
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > > I think one should use project code style for
> > everyday 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?
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov
> > mr.weider@gmail.com:
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > > > I guess that was about failing build
> > configuration with
> > > >> > >> > > > > Checkstype,
> > > >> > >> > > > > > > not
> > > >> > >> > > > > > > > > > compilation build itself.
> > > >> > >> > > > > > > > > >
> > > >> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <
> > vololo100@gmail.com>
> > > >> > >> > > > > > > wrote:
> > > >> > >> > > > > > > > > > >
> > > >> > >> > > > > > > > > > > Folks,
> > > >> > >> > > > > > > > > > >
> > > >> > >> > > > > > > > > > > Are you going to fail job compiling Ignite
> > sources [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
> > convenient to skip some
> > > >> > >> > > > > style
> > > >> > >> > > > > > > > > > > requirements for such sketches (e.g. well
> > formed javadocs).
> > > >> > >> > > > > > > > > > >
> > > >> > >> > > > > > > > > > > [1]
> > > >> > >> > > > > > > > > >
> > > >> > >> > > > > > >
> > > >> > >> > > > >
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > >> > >> > > > > > > > > > >
> > > >> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay
> > Izhikov <
> > > >> > >> > > > > nizhikov@apache.org
> > > >> > >> > > > > > > >:
> > > >> > >> > > > > > > > > > >>
> > > >> > >> > > > > > > > > > >> Petr, we should have 1 configuration for
> > project, may be 1
> > > >> > >> > > > > > > configuration
> > > >> > >> > > > > > > > > > >> per programming language.
> > > >> > >> > > > > > > > > > >>
> > > >> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
> > mr.weider@gmail.com:
> > > >> > >> > > > > > > > > > >>
> > > >> > >> > > > > > > > > > >>> I was asking about how many build
> > configuration is intended?
> > > >> > >> > > > > One
> > > >> > >> > > > > > > for
> > > >> > >> > > > > > > > > > all
> > > >> > >> > > > > > > > > > >>> and multiple per module?
> > > >> > >> > > > > > > > > > >>>
> > > >> > >> > > > > > > > > > >>> With IDEA inspections it was going to be
> > build 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
> > build task? And each
> > > >> > >> > > > > > > module
> > > >> > >> > > > > > > > > > builds
> > > >> > >> > > > > > > > > > >>>> when it required? If yes, then I propose
> > to create a task
> > > >> > >> > > > > like
> > > >> > >> > > > > > > > > > "Licence
> > > >> > >> > > > > > > > > > >>>> check" which will be run for every patch.
> > > >> > >> > > > > > > > > > >>>>
> > > >> > >> > > > > > > > > > >>>> My point is that violation of codestyle
> > should be treated as
> > > >> > >> > > > > > > hard as
> > > >> > >> > > > > > > > > > >>>> compile error.
> > > >> > >> > > > > > > > > > >>>>
> > > >> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
> > mr.weider@gmail.com
> > > >> > >> > > > > :
> > > >> > >> > > > > > > > > > >>>>
> > > >> > >> > > > > > > > > > >>>>> Is build configuration Inspections
> > [Core] meant to
> > > >> > >> > > > > transform
> > > >> > >> > > > > > > into
> > > >> > >> > > > > > > > > > single
> > > >> > >> > > > > > > > > > >>>>> all-modules check build configuration
> > (without module
> > > >> > >> > > > > > > subdivision)?
> > > >> > >> > > > > > > > > > >>>>>
> > > >> > >> > > > > > > > > > >>>>>
> > > >> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay
> > Izhikov <
> > > >> > >> > > > > > > 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/1065-checkstyle-idea
> > > >> > >> > > > > > > > > > >>>>>>
> > > >> > >> > > > > > > > > > >>>>>> I propose do the following:
> > > >> > >> > > > > > > > > > >>>>>>
> > > >> > >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > >> > >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules.
> > Currently, 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
> > Apache Ignite"
> > > >> > >> > > > > suite.
> > > >> > >> > > > > > > Ignite
> > > >> > >> > > > > > > > > > has
> > > >> > >> > > > > > > > > > >>>>> to
> > > >> > >> > > > > > > > > > >>>>>> fail to build if patch violates
> > codestyle.
> > > >> > >> > > > > > > > > > >>>>>>
> > > >> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин
> > Иван <
> > > >> > >> > > > > > > vololo100@gmail.com>:
> > > >> > >> > > > > > > > > > >>>>>>
> > > >> > >> > > > > > > > > > >>>>>>> Hi,
> > > >> > >> > > > > > > > > > >>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>> I also think that some warning from
> > IDEA that some code
> > > >> > >> > > > > > > style rule
> > > >> > >> > > > > > > > > > is
> > > >> > >> > > > > > > > > > >>>>>>> violated is a must-have.
> > > >> > >> > > > > > > > > > >>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58,
> > oignatenko <
> > > >> > >> > > > > > > oignatenko@gridgain.com
> > > >> > >> > > > > > > > > > >:
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>> I believe that whatever style checks
> > we establish at
> > > >> > >> > > > > > > Teamcity, we
> > > >> > >> > > > > > > > > > >>>>> better
> > > >> > >> > > > > > > > > > >>>>>>>> take care of making it easy for
> > developers to find and
> > > >> > >> > > > > fix
> > > >> > >> > > > > > > > > > violations
> > > >> > >> > > > > > > > > > >>>>> in
> > > >> > >> > > > > > > > > > >>>>>>>> their typical dev environment (for
> > Ignite this means, in
> > > >> > >> > > > > > > IDEA). I
> > > >> > >> > > > > > > > > > >>> think
> > > >> > >> > > > > > > > > > >>>>>>> it
> > > >> > >> > > > > > > > > > >>>>>>>> is important that developers can
> > maintain 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
> > just 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
> > checkstyle - I
> > > >> > >> > > > > recommend
> > > >> > >> > > > > > > keeping
> > > >> > >> > > > > > > > > > >>> its
> > > >> > >> > > > > > > > > > >>>>>>>> config file somewhere in the project
> > under version
> > > >> > >> > > > > control.
> > > >> > >> > > > > > > I
> > > >> > >> > > > > > > > > > used to
> > > >> > >> > > > > > > > > > >>>>>>>> maintain such a shared style config
> > at one of past jobs
> > > >> > >> > > > > and
> > > >> > >> > > > > > > after
> > > >> > >> > > > > > > > > > >>> some
> > > >> > >> > > > > > > > > > >>>>>>>> experimenting it turned out most
> > convenient to have it
> > > >> > >> > > > > this
> > > >> > >> > > > > > > way -
> > > >> > >> > > > > > > > > > so
> > > >> > >> > > > > > > > > > >>>>> that
> > > >> > >> > > > > > > > > > >>>>>>>> developers could easily assess and
> > discuss style
> > > >> > >> > > > > settings
> > > >> > >> > > > > > > and keep
> > > >> > >> > > > > > > > > > >>>>> track
> > > >> > >> > > > > > > > > > >>>>>>> of
> > > >> > >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka
> > folks 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
> > community members.
> > > >> > >> > > > > > > Moreover, this
> > > >> > >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we
> > previously
> > > >> > >> > > > > 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
> > consider the Apache Kafka
> > > >> > >> > > > > > > code
> > > >> > >> > > > > > > > > > style
> > > >> > >> > > > > > > > > > >>> [5]
> > > >> > >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite
> > project a
> > > >> > >> > > > > > > > > > maven-checkstyle-plugin
> > > >> > >> > > > > > > > > > >>>>>>>>> with its own maven profile and run
> > it simultaneously
> > > >> > >> > > > > with
> > > >> > >> > > > > > > other
> > > >> > >> > > > > > > > > > TC.
> > > >> > >> > > > > > > > > > >>> We
> > > >> > >> > > > > > > > > > >>>>>>>>> can also enable the previously
> > configured inspection
> > > >> > >> > > > > > > rules, so no
> > > >> > >> > > > > > > > > > >>>>>>>>> coding style violations will be
> > missed.
> > > >> > >> > > > > > > > > > >>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> I see some advantages of using a
> > maven plugin:
> > > >> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > >> > >> > > > > > > > > > >>>>>>>>> - can be used with different CI and
> > build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > >> > >> > > > > > > > > > >>>>>>>>> [2]
> > https://youtrack.jetbrains.com/issue/TW-58504
> > > >> > >> > > > > > > > > > >>>>>>>>> [3]
> > > >> > >> > > > > > > > > > >>>>>>>
> > > >> > >> > > > > > > > > > >>>>>
> > > >> > >> > > > > > > > > > >>>
> > > >> > >> > > > > > > > > >
> > > >> > >> > > > > > >
> > > >> > >> > > > >
> > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > >> > >> > > > > > > > > > >>>>>>>>> [4]
> > https://issues.apache.org/jira/browse/IGNITE-11277
> > > >> > >> > > > > > > > > > >>>>>>>>> [5]
> > > >> > >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > >> > >> > > > > > > > > > >>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr
> > Ivanov &lt;
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest
> > 2018.2 TeamCity
> > > >> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>> [1]
> > https://youtrack.jetbrains.com/issue/TW-58504
> > > >> > >> > > > > > > > > > >>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr
> > Ivanov &lt;
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy
> > Pavlov &lt;
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> dpavlov@
> > > >> > >> > > > > > > > > > >>>>>>>>
> > > >> > >> > > > > > > > > > >>>>>>>>> &gt; 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
> > next 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
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
> >



-- 
Best regards,
Ivan Pavlukhin

Re: Code inspection

[Dmitriy Pavlov <dp...@apache.org>]

Hi Igniters,

I see that a new TeamCity is released: Version: 2018.2.3.

Probably it could solve recently introduced problem related to:
Unexpected error during build messages processing in TeamCity;

Peter I., could you please check?

Sincerely,
Dmitriy Pavlov

пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:

> 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
> today.
>
> 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.
>
> пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
> >
> > 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.
> >
> > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
> > >
> > > +1 to enable code style checks in compile time.
> > >
> > > We can add option to disable maven codestyle profile with some
> environment variable.
> > >
> > > Anyone who want violate common project rules in their local branch can
> set this variable and write some nasty code before push :)
> > >
> > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
> > >>
> > >> 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
> build stage.
> > >> - increases a bit the build time procedure
> > >> - require additional operations to switch it off for prototyping
> branches
> > >>
> > >> + do not require TC.Bot visa if someone of the community doesn't use
> it
> > >> + 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
> needs.
> > >>
> > >> ---
> > >>
> > >> 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+Contribute#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, Павлухин Иван <vo...@gmail.com>
> 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:
> > >> > ====Quoted text====
> > >> > 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.
> > >> > 2. Style check takes some time. With simple checks it is almost
> > >> > negligible. But it can grow if more checks are involved.
> > >> > ====End of quoted text====
> > >> >
> > >> > Some clarifications. 1 is about running from IDEA first. 2 is
> related
> > >> > to opinions that we should involve much more checks, e.g. using
> > >> > abbreviations.
> > >> >
> > >> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> > >> > >
> > >> > > Ivan,
> > >> > >
> > >> > > Let's take a look at all the options we have (ordered by the
> frequency 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
> checkstyle plugin is used in the <build> 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.
> > >> > >
> > >> > > Back to our use cases:
> > >> > >
> > >> > > 1. For checking the ready to merge branches we will fail the
> ~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.
> > >> > >
> > >> > > 2. For the prototyping branches, you can turn off checkstyle in
> your 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
> checkstyle enabled profile. The common build action as `mvn clean install
> -DskipTests` will activate the profile.
> > >> > >
> > >> > > 4. The checkstyle profile can be disabled explicitly on TC by
> specifying -P !checkstyle option. A don't see any use cases of it, but it's
> completely doable.
> > >> > >
> > >> > > Please, correct me if I've missed something.
> > >> > >
> > >> > > I propose to merge PR [1] as it is, with the configured set of
> rules.
> > >> > >
> > >> > > [1] https://github.com/apache/ignite/pull/6119
> > >> > >
> > >> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com>
> wrote:
> > >> > >>
> > >> > >> Maxim,
> > >> > >>
> > >> > >> I like an idea of being IDE agnostic. I am ok with currently
> enabled
> > >> > >> 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
> 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.
> > >> > >> 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"
> which I
> > >> > >> think is quite useful.
> > >> > >>
> > >> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <maxmuzaf@gmail.com
> >:
> > >> > >> >
> > >> > >> > Ivan,
> > >> > >> >
> > >> > >> > I like that Jetbrains inspections are integrated with IDE and
> TC 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
> with code
> > >> > >> > style checking. I've checked popular java projects: hadoop,
> kafka,
> > >> > >> > spark, hive, netty. All of them are using
> maven-checkstyle-plugin in
> > >> > >> > their <build> 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
> and
> > >> > >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose
> to 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-1018
> > >> > >> > [4]
> https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > >> > >> > [5] http://checkstyle.sourceforge.net/checks.html
> > >> > >> >
> > >> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <
> vololo100@gmail.com> 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
> checkstyle
> > >> > >> > > plugin? Is it integrated into IDEA out of box? As I got it
> additional
> > >> > >> > > 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
> visa. Visa
> > >> > >> > > includes result from running inspections job.
> > >> > >> > >
> > >> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> nizhikov@apache.org>:
> > >> > >> > > >
> > >> > >> > > > 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.
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> vololo100@gmail.com>:
> > >> > >> > > >
> > >> > >> > > > > Nikolay,
> > >> > >> > > > >
> > >> > >> > > > > > Should the community spend TC resources for  prototype?
> > >> > >> > > > > Why not? I think it is not bad idea to run all tests
> against 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
> with other
> > >> > >> > > > > Igniters. I think it is the cheapest way to check the
> idea because the
> > >> > >> > > > > check is fully automated. Requiring a human feedback is
> much 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
> skipping tests
> > >> > >> > > > > execution if inspections detect a problem?
> > >> > >> > > > >
> > >> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
> nizhikov@apache.org>:
> > >> > >> > > > > >
> > >> > >> > > > > > 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
> prototype.
> > >> > >> > > > > >
> > >> > >> > > > > > 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?
> > >> > >> > > > > >
> > >> > >> > > > > >
> > >> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
> vololo100@gmail.com>:
> > >> > >> > > > > >
> > >> > >> > > > > > > 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
> outline 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
> that message).
> > >> > >> > > > > > >
> > >> > >> > > > > > > We have a document defining code style which every
> contributor should
> > >> > >> > > > > > > follow [1]. And many points can be checked
> automatically. Personally,
> > >> > >> > > > > > > I do not see much need in writing good javadocs for
> prototype. Why
> > >> > >> > > > > > > should I stub it to be able run any build on TC?
> > >> > >> > > > > > >
> > >> > >> > > > > > > Also, we a have a review process which should be
> applied to every
> > >> > >> > > > > > > patch. Partially it is described in [2]. And due to
> this process every
> > >> > >> > > > > > > patch should not introduce new failures on TC. So,
> the patch should
> > >> > >> > > > > > > not be merged if inspections failed.
> > >> > >> > > > > > >
> > >> > >> > > > > > > P.S. Something more about prototypes and production
> code. There is a
> > >> > >> > > > > > > common bad practice in software engineering. It is
> turning prototypes
> > >> > >> > > > > > > into production code. Often it is much faster to
> create a prototype by
> > >> > >> > > > > > > price of violating some rules of writing "clean
> code". And often
> > >> > >> > > > > > > prototype after successful piloting is turned into
> production code.
> > >> > >> > > > > > > And it is very easy in practice to keep some pieces
> of 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"
> from the beginning.
> > >> > >> > > > > > > So, only ideas are taken from the prototype and a
> code is fully
> > >> > >> > > > > > > rewritten.
> > >> > >> > > > > > >
> > >> > >> > > > > > > [1]
> > >> > >> > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > >> > >> > > > > > > [2]
> > >> > >> > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > >> > >> > > > > > >
> > >> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
> maxmuzaf@gmail.com>:
> > >> > >> > > > > > > >
> > >> > >> > > > > > > > Ivan,
> > >> > >> > > > > > > >
> > >> > >> > > > > > > > As the first implementation of this addition, I'd
> prefer to make it
> > >> > >> > > > > > > > working like _Licenses Headers_ suite check. It
> will fail when some
> > >> > >> > > > > of
> > >> > >> > > > > > > > the code style checks violated. Moreover, these
> licenses header
> > >> > >> > > > > checks
> > >> > >> > > > > > > > can be included in the checkstyle plugin
> configuration.
> > >> > >> > > > > > > >
> > >> > >> > > > > > > > In general, I'd prefer to have a compilation fail
> error with code
> > >> > >> > > > > > > > style checks and after we will get a stable
> checkstyle suite I
> > >> > >> > > > > propose
> > >> > >> > > > > > > > to change it in a "compilation error" way. If we
> are talking about
> > >> > >> > > > > the
> > >> > >> > > > > > > > coding style convenient for most of the community
> members I see no
> > >> > >> > > > > > > > difference with coding sketches or
> production-ready branches equally.
> > >> > >> > > > > > > > Indeed, no one will be against unused imports [or
> spaces 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() == 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 <
> nizhikov@apache.org>
> > >> > >> > > > > > > wrote:
> > >> > >> > > > > > > > >
> > >> > >> > > > > > > > > Actually, I dont see anything wrong with failing
> *compilation*
> > >> > >> > > > > task.
> > >> > >> > > > > > > > >
> > >> > >> > > > > > > > > I think one should use project code style for
> everyday 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?
> > >> > >> > > > > > > > >
> > >> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov
> mr.weider@gmail.com:
> > >> > >> > > > > > > > >
> > >> > >> > > > > > > > > > I guess that was about failing build
> configuration with
> > >> > >> > > > > Checkstype,
> > >> > >> > > > > > > not
> > >> > >> > > > > > > > > > compilation build itself.
> > >> > >> > > > > > > > > >
> > >> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <
> vololo100@gmail.com>
> > >> > >> > > > > > > wrote:
> > >> > >> > > > > > > > > > >
> > >> > >> > > > > > > > > > > Folks,
> > >> > >> > > > > > > > > > >
> > >> > >> > > > > > > > > > > Are you going to fail job compiling Ignite
> sources [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
> convenient to skip some
> > >> > >> > > > > style
> > >> > >> > > > > > > > > > > requirements for such sketches (e.g. well
> formed javadocs).
> > >> > >> > > > > > > > > > >
> > >> > >> > > > > > > > > > > [1]
> > >> > >> > > > > > > > > >
> > >> > >> > > > > > >
> > >> > >> > > > >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > >> > >> > > > > > > > > > >
> > >> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay
> Izhikov <
> > >> > >> > > > > nizhikov@apache.org
> > >> > >> > > > > > > >:
> > >> > >> > > > > > > > > > >>
> > >> > >> > > > > > > > > > >> Petr, we should have 1 configuration for
> project, may be 1
> > >> > >> > > > > > > configuration
> > >> > >> > > > > > > > > > >> per programming language.
> > >> > >> > > > > > > > > > >>
> > >> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
> mr.weider@gmail.com:
> > >> > >> > > > > > > > > > >>
> > >> > >> > > > > > > > > > >>> I was asking about how many build
> configuration is intended?
> > >> > >> > > > > One
> > >> > >> > > > > > > for
> > >> > >> > > > > > > > > > all
> > >> > >> > > > > > > > > > >>> and multiple per module?
> > >> > >> > > > > > > > > > >>>
> > >> > >> > > > > > > > > > >>> With IDEA inspections it was going to be
> build 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
> build task? And each
> > >> > >> > > > > > > module
> > >> > >> > > > > > > > > > builds
> > >> > >> > > > > > > > > > >>>> when it required? If yes, then I propose
> to create a task
> > >> > >> > > > > like
> > >> > >> > > > > > > > > > "Licence
> > >> > >> > > > > > > > > > >>>> check" which will be run for every patch.
> > >> > >> > > > > > > > > > >>>>
> > >> > >> > > > > > > > > > >>>> My point is that violation of codestyle
> should be treated as
> > >> > >> > > > > > > hard as
> > >> > >> > > > > > > > > > >>>> compile error.
> > >> > >> > > > > > > > > > >>>>
> > >> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
> mr.weider@gmail.com
> > >> > >> > > > > :
> > >> > >> > > > > > > > > > >>>>
> > >> > >> > > > > > > > > > >>>>> Is build configuration Inspections
> [Core] meant to
> > >> > >> > > > > transform
> > >> > >> > > > > > > into
> > >> > >> > > > > > > > > > single
> > >> > >> > > > > > > > > > >>>>> all-modules check build configuration
> (without module
> > >> > >> > > > > > > subdivision)?
> > >> > >> > > > > > > > > > >>>>>
> > >> > >> > > > > > > > > > >>>>>
> > >> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay
> Izhikov <
> > >> > >> > > > > > > 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/1065-checkstyle-idea
> > >> > >> > > > > > > > > > >>>>>>
> > >> > >> > > > > > > > > > >>>>>> I propose do the following:
> > >> > >> > > > > > > > > > >>>>>>
> > >> > >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > >> > >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules.
> Currently, 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
> Apache Ignite"
> > >> > >> > > > > suite.
> > >> > >> > > > > > > Ignite
> > >> > >> > > > > > > > > > has
> > >> > >> > > > > > > > > > >>>>> to
> > >> > >> > > > > > > > > > >>>>>> fail to build if patch violates
> codestyle.
> > >> > >> > > > > > > > > > >>>>>>
> > >> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин
> Иван <
> > >> > >> > > > > > > vololo100@gmail.com>:
> > >> > >> > > > > > > > > > >>>>>>
> > >> > >> > > > > > > > > > >>>>>>> Hi,
> > >> > >> > > > > > > > > > >>>>>>>
> > >> > >> > > > > > > > > > >>>>>>> I also think that some warning from
> IDEA that some code
> > >> > >> > > > > > > style rule
> > >> > >> > > > > > > > > > is
> > >> > >> > > > > > > > > > >>>>>>> violated is a must-have.
> > >> > >> > > > > > > > > > >>>>>>>
> > >> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58,
> oignatenko <
> > >> > >> > > > > > > oignatenko@gridgain.com
> > >> > >> > > > > > > > > > >:
> > >> > >> > > > > > > > > > >>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
> > >> > >> > > > > > > > > > >>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>> I believe that whatever style checks
> we establish at
> > >> > >> > > > > > > Teamcity, we
> > >> > >> > > > > > > > > > >>>>> better
> > >> > >> > > > > > > > > > >>>>>>>> take care of making it easy for
> developers to find and
> > >> > >> > > > > fix
> > >> > >> > > > > > > > > > violations
> > >> > >> > > > > > > > > > >>>>> in
> > >> > >> > > > > > > > > > >>>>>>>> their typical dev environment (for
> Ignite this means, in
> > >> > >> > > > > > > IDEA). I
> > >> > >> > > > > > > > > > >>> think
> > >> > >> > > > > > > > > > >>>>>>> it
> > >> > >> > > > > > > > > > >>>>>>>> is important that developers can
> maintain 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
> just 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
> checkstyle - I
> > >> > >> > > > > recommend
> > >> > >> > > > > > > keeping
> > >> > >> > > > > > > > > > >>> its
> > >> > >> > > > > > > > > > >>>>>>>> config file somewhere in the project
> under version
> > >> > >> > > > > control.
> > >> > >> > > > > > > I
> > >> > >> > > > > > > > > > used to
> > >> > >> > > > > > > > > > >>>>>>>> maintain such a shared style config
> at one of past jobs
> > >> > >> > > > > and
> > >> > >> > > > > > > after
> > >> > >> > > > > > > > > > >>> some
> > >> > >> > > > > > > > > > >>>>>>>> experimenting it turned out most
> convenient to have it
> > >> > >> > > > > this
> > >> > >> > > > > > > way -
> > >> > >> > > > > > > > > > so
> > >> > >> > > > > > > > > > >>>>> that
> > >> > >> > > > > > > > > > >>>>>>>> developers could easily assess and
> discuss style
> > >> > >> > > > > settings
> > >> > >> > > > > > > and keep
> > >> > >> > > > > > > > > > >>>>> track
> > >> > >> > > > > > > > > > >>>>>>> of
> > >> > >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka
> folks 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
> community members.
> > >> > >> > > > > > > Moreover, this
> > >> > >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we
> previously
> > >> > >> > > > > 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
> consider the Apache Kafka
> > >> > >> > > > > > > code
> > >> > >> > > > > > > > > > style
> > >> > >> > > > > > > > > > >>> [5]
> > >> > >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite
> project a
> > >> > >> > > > > > > > > > maven-checkstyle-plugin
> > >> > >> > > > > > > > > > >>>>>>>>> with its own maven profile and run
> it simultaneously
> > >> > >> > > > > with
> > >> > >> > > > > > > other
> > >> > >> > > > > > > > > > TC.
> > >> > >> > > > > > > > > > >>> We
> > >> > >> > > > > > > > > > >>>>>>>>> can also enable the previously
> configured inspection
> > >> > >> > > > > > > rules, so no
> > >> > >> > > > > > > > > > >>>>>>>>> coding style violations will be
> missed.
> > >> > >> > > > > > > > > > >>>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>> I see some advantages of using a
> maven plugin:
> > >> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > >> > >> > > > > > > > > > >>>>>>>>> - can be used with different CI and
> build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > >> > >> > > > > > > > > > >>>>>>>>> [2]
> https://youtrack.jetbrains.com/issue/TW-58504
> > >> > >> > > > > > > > > > >>>>>>>>> [3]
> > >> > >> > > > > > > > > > >>>>>>>
> > >> > >> > > > > > > > > > >>>>>
> > >> > >> > > > > > > > > > >>>
> > >> > >> > > > > > > > > >
> > >> > >> > > > > > >
> > >> > >> > > > >
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > >> > >> > > > > > > > > > >>>>>>>>> [4]
> https://issues.apache.org/jira/browse/IGNITE-11277
> > >> > >> > > > > > > > > > >>>>>>>>> [5]
> > >> > >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > >> > >> > > > > > > > > > >>>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr
> Ivanov &lt;
> > >> > >> > > > > > > > > > >>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > >> > >> > > > > > > > > > >>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > >> > >> > > > > > > > > > >>>>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest
> 2018.2 TeamCity
> > >> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> > >> > >> > > > > > > > > > >>>>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>>> [1]
> https://youtrack.jetbrains.com/issue/TW-58504
> > >> > >> > > > > > > > > > >>>>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr
> Ivanov &lt;
> > >> > >> > > > > > > > > > >>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > >> > >> > > > > > > > > > >>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > >> > >> > > > > > > > > > >>>>>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > >> > >> > > > > > > > > > >>>>>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy
> Pavlov &lt;
> > >> > >> > > > > > > > > > >>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>> dpavlov@
> > >> > >> > > > > > > > > > >>>>>>>>
> > >> > >> > > > > > > > > > >>>>>>>>> &gt; 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
> next 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
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
>

Re: Code inspection

[Павлухин Иван <vo...@gmail.com>]

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 today.

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.

пт, 15 мар. 2019 г. в 12:04, Павлухин Иван <vo...@gmail.com>:
>
> 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.
>
> пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
> >
> > +1 to enable code style checks in compile time.
> >
> > We can add option to disable maven codestyle profile with some environment variable.
> >
> > Anyone who want violate common project rules in their local branch can set this variable and write some nasty code before push :)
> >
> > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
> >>
> >> 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 build stage.
> >> - increases a bit the build time procedure
> >> - require additional operations to switch it off for prototyping branches
> >>
> >> + do not require TC.Bot visa if someone of the community doesn't use it
> >> + 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 needs.
> >>
> >> ---
> >>
> >> 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+Contribute#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, Павлухин Иван <vo...@gmail.com> 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:
> >> > ====Quoted text====
> >> > 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.
> >> > 2. Style check takes some time. With simple checks it is almost
> >> > negligible. But it can grow if more checks are involved.
> >> > ====End of quoted text====
> >> >
> >> > Some clarifications. 1 is about running from IDEA first. 2 is related
> >> > to opinions that we should involve much more checks, e.g. using
> >> > abbreviations.
> >> >
> >> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> >> > >
> >> > > Ivan,
> >> > >
> >> > > Let's take a look at all the options we have (ordered by the frequency 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 checkstyle plugin is used in the <build> 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.
> >> > >
> >> > > Back to our use cases:
> >> > >
> >> > > 1. For checking the ready to merge branches we will fail the ~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.
> >> > >
> >> > > 2. For the prototyping branches, you can turn off checkstyle in your 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 checkstyle enabled profile. The common build action as `mvn clean install -DskipTests` will activate the profile.
> >> > >
> >> > > 4. The checkstyle profile can be disabled explicitly on TC by specifying -P !checkstyle option. A don't see any use cases of it, but it's completely doable.
> >> > >
> >> > > Please, correct me if I've missed something.
> >> > >
> >> > > I propose to merge PR [1] as it is, with the configured set of rules.
> >> > >
> >> > > [1] https://github.com/apache/ignite/pull/6119
> >> > >
> >> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com> wrote:
> >> > >>
> >> > >> Maxim,
> >> > >>
> >> > >> I like an idea of being IDE agnostic. I am ok with currently enabled
> >> > >> 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 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.
> >> > >> 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" which I
> >> > >> think is quite useful.
> >> > >>
> >> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <ma...@gmail.com>:
> >> > >> >
> >> > >> > Ivan,
> >> > >> >
> >> > >> > I like that Jetbrains inspections are integrated with IDE and TC 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 with code
> >> > >> > style checking. I've checked popular java projects: hadoop, kafka,
> >> > >> > spark, hive, netty. All of them are using maven-checkstyle-plugin in
> >> > >> > their <build> 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 and
> >> > >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose to 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-1018
> >> > >> > [4] https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> >> > >> > [5] http://checkstyle.sourceforge.net/checks.html
> >> > >> >
> >> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <vo...@gmail.com> 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 checkstyle
> >> > >> > > plugin? Is it integrated into IDEA out of box? As I got it additional
> >> > >> > > 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 visa. Visa
> >> > >> > > includes result from running inspections job.
> >> > >> > >
> >> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <ni...@apache.org>:
> >> > >> > > >
> >> > >> > > > 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.
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <vo...@gmail.com>:
> >> > >> > > >
> >> > >> > > > > Nikolay,
> >> > >> > > > >
> >> > >> > > > > > Should the community spend TC resources for  prototype?
> >> > >> > > > > Why not? I think it is not bad idea to run all tests against 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 with other
> >> > >> > > > > Igniters. I think it is the cheapest way to check the idea because the
> >> > >> > > > > check is fully automated. Requiring a human feedback is much 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 skipping tests
> >> > >> > > > > execution if inspections detect a problem?
> >> > >> > > > >
> >> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <ni...@apache.org>:
> >> > >> > > > > >
> >> > >> > > > > > 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 prototype.
> >> > >> > > > > >
> >> > >> > > > > > 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?
> >> > >> > > > > >
> >> > >> > > > > >
> >> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <vo...@gmail.com>:
> >> > >> > > > > >
> >> > >> > > > > > > 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 outline 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 that message).
> >> > >> > > > > > >
> >> > >> > > > > > > We have a document defining code style which every contributor should
> >> > >> > > > > > > follow [1]. And many points can be checked automatically. Personally,
> >> > >> > > > > > > I do not see much need in writing good javadocs for prototype. Why
> >> > >> > > > > > > should I stub it to be able run any build on TC?
> >> > >> > > > > > >
> >> > >> > > > > > > Also, we a have a review process which should be applied to every
> >> > >> > > > > > > patch. Partially it is described in [2]. And due to this process every
> >> > >> > > > > > > patch should not introduce new failures on TC. So, the patch should
> >> > >> > > > > > > not be merged if inspections failed.
> >> > >> > > > > > >
> >> > >> > > > > > > P.S. Something more about prototypes and production code. There is a
> >> > >> > > > > > > common bad practice in software engineering. It is turning prototypes
> >> > >> > > > > > > into production code. Often it is much faster to create a prototype by
> >> > >> > > > > > > price of violating some rules of writing "clean code". And often
> >> > >> > > > > > > prototype after successful piloting is turned into production code.
> >> > >> > > > > > > And it is very easy in practice to keep some pieces of 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" from the beginning.
> >> > >> > > > > > > So, only ideas are taken from the prototype and a code is fully
> >> > >> > > > > > > rewritten.
> >> > >> > > > > > >
> >> > >> > > > > > > [1]
> >> > >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> >> > >> > > > > > > [2]
> >> > >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> >> > >> > > > > > >
> >> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <ma...@gmail.com>:
> >> > >> > > > > > > >
> >> > >> > > > > > > > Ivan,
> >> > >> > > > > > > >
> >> > >> > > > > > > > As the first implementation of this addition, I'd prefer to make it
> >> > >> > > > > > > > working like _Licenses Headers_ suite check. It will fail when some
> >> > >> > > > > of
> >> > >> > > > > > > > the code style checks violated. Moreover, these licenses header
> >> > >> > > > > checks
> >> > >> > > > > > > > can be included in the checkstyle plugin configuration.
> >> > >> > > > > > > >
> >> > >> > > > > > > > In general, I'd prefer to have a compilation fail error with code
> >> > >> > > > > > > > style checks and after we will get a stable checkstyle suite I
> >> > >> > > > > propose
> >> > >> > > > > > > > to change it in a "compilation error" way. If we are talking about
> >> > >> > > > > the
> >> > >> > > > > > > > coding style convenient for most of the community members I see no
> >> > >> > > > > > > > difference with coding sketches or production-ready branches equally.
> >> > >> > > > > > > > Indeed, no one will be against unused imports [or spaces 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() == 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 <ni...@apache.org>
> >> > >> > > > > > > wrote:
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > Actually, I dont see anything wrong with failing *compilation*
> >> > >> > > > > task.
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > I think one should use project code style for everyday 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?
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.weider@gmail.com:
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > > I guess that was about failing build configuration with
> >> > >> > > > > Checkstype,
> >> > >> > > > > > > not
> >> > >> > > > > > > > > > compilation build itself.
> >> > >> > > > > > > > > >
> >> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <vo...@gmail.com>
> >> > >> > > > > > > wrote:
> >> > >> > > > > > > > > > >
> >> > >> > > > > > > > > > > Folks,
> >> > >> > > > > > > > > > >
> >> > >> > > > > > > > > > > Are you going to fail job compiling Ignite sources [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 convenient to skip some
> >> > >> > > > > style
> >> > >> > > > > > > > > > > requirements for such sketches (e.g. well formed javadocs).
> >> > >> > > > > > > > > > >
> >> > >> > > > > > > > > > > [1]
> >> > >> > > > > > > > > >
> >> > >> > > > > > >
> >> > >> > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> >> > >> > > > > > > > > > >
> >> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <
> >> > >> > > > > nizhikov@apache.org
> >> > >> > > > > > > >:
> >> > >> > > > > > > > > > >>
> >> > >> > > > > > > > > > >> Petr, we should have 1 configuration for project, may be 1
> >> > >> > > > > > > configuration
> >> > >> > > > > > > > > > >> per programming language.
> >> > >> > > > > > > > > > >>
> >> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
> >> > >> > > > > > > > > > >>
> >> > >> > > > > > > > > > >>> I was asking about how many build configuration is intended?
> >> > >> > > > > One
> >> > >> > > > > > > for
> >> > >> > > > > > > > > > all
> >> > >> > > > > > > > > > >>> and multiple per module?
> >> > >> > > > > > > > > > >>>
> >> > >> > > > > > > > > > >>> With IDEA inspections it was going to be build 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 build task? And each
> >> > >> > > > > > > module
> >> > >> > > > > > > > > > builds
> >> > >> > > > > > > > > > >>>> when it required? If yes, then I propose to create a task
> >> > >> > > > > like
> >> > >> > > > > > > > > > "Licence
> >> > >> > > > > > > > > > >>>> check" which will be run for every patch.
> >> > >> > > > > > > > > > >>>>
> >> > >> > > > > > > > > > >>>> My point is that violation of codestyle should be treated as
> >> > >> > > > > > > hard as
> >> > >> > > > > > > > > > >>>> compile error.
> >> > >> > > > > > > > > > >>>>
> >> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com
> >> > >> > > > > :
> >> > >> > > > > > > > > > >>>>
> >> > >> > > > > > > > > > >>>>> Is build configuration Inspections [Core] meant to
> >> > >> > > > > transform
> >> > >> > > > > > > into
> >> > >> > > > > > > > > > single
> >> > >> > > > > > > > > > >>>>> all-modules check build configuration (without module
> >> > >> > > > > > > subdivision)?
> >> > >> > > > > > > > > > >>>>>
> >> > >> > > > > > > > > > >>>>>
> >> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <
> >> > >> > > > > > > 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/1065-checkstyle-idea
> >> > >> > > > > > > > > > >>>>>>
> >> > >> > > > > > > > > > >>>>>> I propose do the following:
> >> > >> > > > > > > > > > >>>>>>
> >> > >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> >> > >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite"
> >> > >> > > > > suite.
> >> > >> > > > > > > Ignite
> >> > >> > > > > > > > > > has
> >> > >> > > > > > > > > > >>>>> to
> >> > >> > > > > > > > > > >>>>>> fail to build if patch violates codestyle.
> >> > >> > > > > > > > > > >>>>>>
> >> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <
> >> > >> > > > > > > vololo100@gmail.com>:
> >> > >> > > > > > > > > > >>>>>>
> >> > >> > > > > > > > > > >>>>>>> Hi,
> >> > >> > > > > > > > > > >>>>>>>
> >> > >> > > > > > > > > > >>>>>>> I also think that some warning from IDEA that some code
> >> > >> > > > > > > style rule
> >> > >> > > > > > > > > > is
> >> > >> > > > > > > > > > >>>>>>> violated is a must-have.
> >> > >> > > > > > > > > > >>>>>>>
> >> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <
> >> > >> > > > > > > oignatenko@gridgain.com
> >> > >> > > > > > > > > > >:
> >> > >> > > > > > > > > > >>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
> >> > >> > > > > > > > > > >>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>> I believe that whatever style checks we establish at
> >> > >> > > > > > > Teamcity, we
> >> > >> > > > > > > > > > >>>>> better
> >> > >> > > > > > > > > > >>>>>>>> take care of making it easy for developers to find and
> >> > >> > > > > fix
> >> > >> > > > > > > > > > violations
> >> > >> > > > > > > > > > >>>>> in
> >> > >> > > > > > > > > > >>>>>>>> their typical dev environment (for Ignite this means, in
> >> > >> > > > > > > IDEA). I
> >> > >> > > > > > > > > > >>> think
> >> > >> > > > > > > > > > >>>>>>> it
> >> > >> > > > > > > > > > >>>>>>>> is important that developers can maintain 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 just 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 checkstyle - I
> >> > >> > > > > recommend
> >> > >> > > > > > > keeping
> >> > >> > > > > > > > > > >>> its
> >> > >> > > > > > > > > > >>>>>>>> config file somewhere in the project under version
> >> > >> > > > > control.
> >> > >> > > > > > > I
> >> > >> > > > > > > > > > used to
> >> > >> > > > > > > > > > >>>>>>>> maintain such a shared style config at one of past jobs
> >> > >> > > > > and
> >> > >> > > > > > > after
> >> > >> > > > > > > > > > >>> some
> >> > >> > > > > > > > > > >>>>>>>> experimenting it turned out most convenient to have it
> >> > >> > > > > this
> >> > >> > > > > > > way -
> >> > >> > > > > > > > > > so
> >> > >> > > > > > > > > > >>>>> that
> >> > >> > > > > > > > > > >>>>>>>> developers could easily assess and discuss style
> >> > >> > > > > settings
> >> > >> > > > > > > and keep
> >> > >> > > > > > > > > > >>>>> track
> >> > >> > > > > > > > > > >>>>>>> of
> >> > >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka folks 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 community members.
> >> > >> > > > > > > Moreover, this
> >> > >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we previously
> >> > >> > > > > 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 consider the Apache Kafka
> >> > >> > > > > > > code
> >> > >> > > > > > > > > > style
> >> > >> > > > > > > > > > >>> [5]
> >> > >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite project a
> >> > >> > > > > > > > > > maven-checkstyle-plugin
> >> > >> > > > > > > > > > >>>>>>>>> with its own maven profile and run it simultaneously
> >> > >> > > > > with
> >> > >> > > > > > > other
> >> > >> > > > > > > > > > TC.
> >> > >> > > > > > > > > > >>> We
> >> > >> > > > > > > > > > >>>>>>>>> can also enable the previously configured inspection
> >> > >> > > > > > > rules, so no
> >> > >> > > > > > > > > > >>>>>>>>> coding style violations will be missed.
> >> > >> > > > > > > > > > >>>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>> I see some advantages of using a maven plugin:
> >> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> >> > >> > > > > > > > > > >>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> >> > >> > > > > > > > > > >>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> >> > >> > > > > > > > > > >>>>>>>>> [3]
> >> > >> > > > > > > > > > >>>>>>>
> >> > >> > > > > > > > > > >>>>>
> >> > >> > > > > > > > > > >>>
> >> > >> > > > > > > > > >
> >> > >> > > > > > >
> >> > >> > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> >> > >> > > > > > > > > > >>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> >> > >> > > > > > > > > > >>>>>>>>> [5]
> >> > >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> >> > >> > > > > > > > > > >>>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> >> > >> > > > > > > > > > >>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> >> > >> > > > > > > > > > >>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> >> > >> > > > > > > > > > >>>>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity
> >> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> >> > >> > > > > > > > > > >>>>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> >> > >> > > > > > > > > > >>>>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> >> > >> > > > > > > > > > >>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> >> > >> > > > > > > > > > >>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> >> > >> > > > > > > > > > >>>>>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> >> > >> > > > > > > > > > >>>>>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> >> > >> > > > > > > > > > >>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>> dpavlov@
> >> > >> > > > > > > > > > >>>>>>>>
> >> > >> > > > > > > > > > >>>>>>>>> &gt; 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 next 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



-- 
Best regards,
Ivan Pavlukhin

Re: Code inspection

[Павлухин Иван <vo...@gmail.com>]

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.

пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov <ni...@apache.org>:
>
> +1 to enable code style checks in compile time.
>
> We can add option to disable maven codestyle profile with some environment variable.
>
> Anyone who want violate common project rules in their local branch can set this variable and write some nasty code before push :)
>
> пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:
>>
>> 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 build stage.
>> - increases a bit the build time procedure
>> - require additional operations to switch it off for prototyping branches
>>
>> + do not require TC.Bot visa if someone of the community doesn't use it
>> + 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 needs.
>>
>> ---
>>
>> 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+Contribute#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, Павлухин Иван <vo...@gmail.com> 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:
>> > ====Quoted text====
>> > 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.
>> > 2. Style check takes some time. With simple checks it is almost
>> > negligible. But it can grow if more checks are involved.
>> > ====End of quoted text====
>> >
>> > Some clarifications. 1 is about running from IDEA first. 2 is related
>> > to opinions that we should involve much more checks, e.g. using
>> > abbreviations.
>> >
>> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
>> > >
>> > > Ivan,
>> > >
>> > > Let's take a look at all the options we have (ordered by the frequency 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 checkstyle plugin is used in the <build> 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.
>> > >
>> > > Back to our use cases:
>> > >
>> > > 1. For checking the ready to merge branches we will fail the ~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.
>> > >
>> > > 2. For the prototyping branches, you can turn off checkstyle in your 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 checkstyle enabled profile. The common build action as `mvn clean install -DskipTests` will activate the profile.
>> > >
>> > > 4. The checkstyle profile can be disabled explicitly on TC by specifying -P !checkstyle option. A don't see any use cases of it, but it's completely doable.
>> > >
>> > > Please, correct me if I've missed something.
>> > >
>> > > I propose to merge PR [1] as it is, with the configured set of rules.
>> > >
>> > > [1] https://github.com/apache/ignite/pull/6119
>> > >
>> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com> wrote:
>> > >>
>> > >> Maxim,
>> > >>
>> > >> I like an idea of being IDE agnostic. I am ok with currently enabled
>> > >> 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 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.
>> > >> 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" which I
>> > >> think is quite useful.
>> > >>
>> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <ma...@gmail.com>:
>> > >> >
>> > >> > Ivan,
>> > >> >
>> > >> > I like that Jetbrains inspections are integrated with IDE and TC 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 with code
>> > >> > style checking. I've checked popular java projects: hadoop, kafka,
>> > >> > spark, hive, netty. All of them are using maven-checkstyle-plugin in
>> > >> > their <build> 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 and
>> > >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose to 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-1018
>> > >> > [4] https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
>> > >> > [5] http://checkstyle.sourceforge.net/checks.html
>> > >> >
>> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <vo...@gmail.com> 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 checkstyle
>> > >> > > plugin? Is it integrated into IDEA out of box? As I got it additional
>> > >> > > 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 visa. Visa
>> > >> > > includes result from running inspections job.
>> > >> > >
>> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <ni...@apache.org>:
>> > >> > > >
>> > >> > > > 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.
>> > >> > > >
>> > >> > > >
>> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <vo...@gmail.com>:
>> > >> > > >
>> > >> > > > > Nikolay,
>> > >> > > > >
>> > >> > > > > > Should the community spend TC resources for  prototype?
>> > >> > > > > Why not? I think it is not bad idea to run all tests against 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 with other
>> > >> > > > > Igniters. I think it is the cheapest way to check the idea because the
>> > >> > > > > check is fully automated. Requiring a human feedback is much 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 skipping tests
>> > >> > > > > execution if inspections detect a problem?
>> > >> > > > >
>> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <ni...@apache.org>:
>> > >> > > > > >
>> > >> > > > > > 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 prototype.
>> > >> > > > > >
>> > >> > > > > > 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?
>> > >> > > > > >
>> > >> > > > > >
>> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <vo...@gmail.com>:
>> > >> > > > > >
>> > >> > > > > > > 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 outline 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 that message).
>> > >> > > > > > >
>> > >> > > > > > > We have a document defining code style which every contributor should
>> > >> > > > > > > follow [1]. And many points can be checked automatically. Personally,
>> > >> > > > > > > I do not see much need in writing good javadocs for prototype. Why
>> > >> > > > > > > should I stub it to be able run any build on TC?
>> > >> > > > > > >
>> > >> > > > > > > Also, we a have a review process which should be applied to every
>> > >> > > > > > > patch. Partially it is described in [2]. And due to this process every
>> > >> > > > > > > patch should not introduce new failures on TC. So, the patch should
>> > >> > > > > > > not be merged if inspections failed.
>> > >> > > > > > >
>> > >> > > > > > > P.S. Something more about prototypes and production code. There is a
>> > >> > > > > > > common bad practice in software engineering. It is turning prototypes
>> > >> > > > > > > into production code. Often it is much faster to create a prototype by
>> > >> > > > > > > price of violating some rules of writing "clean code". And often
>> > >> > > > > > > prototype after successful piloting is turned into production code.
>> > >> > > > > > > And it is very easy in practice to keep some pieces of 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" from the beginning.
>> > >> > > > > > > So, only ideas are taken from the prototype and a code is fully
>> > >> > > > > > > rewritten.
>> > >> > > > > > >
>> > >> > > > > > > [1]
>> > >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
>> > >> > > > > > > [2]
>> > >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
>> > >> > > > > > >
>> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <ma...@gmail.com>:
>> > >> > > > > > > >
>> > >> > > > > > > > Ivan,
>> > >> > > > > > > >
>> > >> > > > > > > > As the first implementation of this addition, I'd prefer to make it
>> > >> > > > > > > > working like _Licenses Headers_ suite check. It will fail when some
>> > >> > > > > of
>> > >> > > > > > > > the code style checks violated. Moreover, these licenses header
>> > >> > > > > checks
>> > >> > > > > > > > can be included in the checkstyle plugin configuration.
>> > >> > > > > > > >
>> > >> > > > > > > > In general, I'd prefer to have a compilation fail error with code
>> > >> > > > > > > > style checks and after we will get a stable checkstyle suite I
>> > >> > > > > propose
>> > >> > > > > > > > to change it in a "compilation error" way. If we are talking about
>> > >> > > > > the
>> > >> > > > > > > > coding style convenient for most of the community members I see no
>> > >> > > > > > > > difference with coding sketches or production-ready branches equally.
>> > >> > > > > > > > Indeed, no one will be against unused imports [or spaces 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() == 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 <ni...@apache.org>
>> > >> > > > > > > wrote:
>> > >> > > > > > > > >
>> > >> > > > > > > > > Actually, I dont see anything wrong with failing *compilation*
>> > >> > > > > task.
>> > >> > > > > > > > >
>> > >> > > > > > > > > I think one should use project code style for everyday 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?
>> > >> > > > > > > > >
>> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.weider@gmail.com:
>> > >> > > > > > > > >
>> > >> > > > > > > > > > I guess that was about failing build configuration with
>> > >> > > > > Checkstype,
>> > >> > > > > > > not
>> > >> > > > > > > > > > compilation build itself.
>> > >> > > > > > > > > >
>> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <vo...@gmail.com>
>> > >> > > > > > > wrote:
>> > >> > > > > > > > > > >
>> > >> > > > > > > > > > > Folks,
>> > >> > > > > > > > > > >
>> > >> > > > > > > > > > > Are you going to fail job compiling Ignite sources [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 convenient to skip some
>> > >> > > > > style
>> > >> > > > > > > > > > > requirements for such sketches (e.g. well formed javadocs).
>> > >> > > > > > > > > > >
>> > >> > > > > > > > > > > [1]
>> > >> > > > > > > > > >
>> > >> > > > > > >
>> > >> > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
>> > >> > > > > > > > > > >
>> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <
>> > >> > > > > nizhikov@apache.org
>> > >> > > > > > > >:
>> > >> > > > > > > > > > >>
>> > >> > > > > > > > > > >> Petr, we should have 1 configuration for project, may be 1
>> > >> > > > > > > configuration
>> > >> > > > > > > > > > >> per programming language.
>> > >> > > > > > > > > > >>
>> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
>> > >> > > > > > > > > > >>
>> > >> > > > > > > > > > >>> I was asking about how many build configuration is intended?
>> > >> > > > > One
>> > >> > > > > > > for
>> > >> > > > > > > > > > all
>> > >> > > > > > > > > > >>> and multiple per module?
>> > >> > > > > > > > > > >>>
>> > >> > > > > > > > > > >>> With IDEA inspections it was going to be build 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 build task? And each
>> > >> > > > > > > module
>> > >> > > > > > > > > > builds
>> > >> > > > > > > > > > >>>> when it required? If yes, then I propose to create a task
>> > >> > > > > like
>> > >> > > > > > > > > > "Licence
>> > >> > > > > > > > > > >>>> check" which will be run for every patch.
>> > >> > > > > > > > > > >>>>
>> > >> > > > > > > > > > >>>> My point is that violation of codestyle should be treated as
>> > >> > > > > > > hard as
>> > >> > > > > > > > > > >>>> compile error.
>> > >> > > > > > > > > > >>>>
>> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com
>> > >> > > > > :
>> > >> > > > > > > > > > >>>>
>> > >> > > > > > > > > > >>>>> Is build configuration Inspections [Core] meant to
>> > >> > > > > transform
>> > >> > > > > > > into
>> > >> > > > > > > > > > single
>> > >> > > > > > > > > > >>>>> all-modules check build configuration (without module
>> > >> > > > > > > subdivision)?
>> > >> > > > > > > > > > >>>>>
>> > >> > > > > > > > > > >>>>>
>> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <
>> > >> > > > > > > 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/1065-checkstyle-idea
>> > >> > > > > > > > > > >>>>>>
>> > >> > > > > > > > > > >>>>>> I propose do the following:
>> > >> > > > > > > > > > >>>>>>
>> > >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
>> > >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite"
>> > >> > > > > suite.
>> > >> > > > > > > Ignite
>> > >> > > > > > > > > > has
>> > >> > > > > > > > > > >>>>> to
>> > >> > > > > > > > > > >>>>>> fail to build if patch violates codestyle.
>> > >> > > > > > > > > > >>>>>>
>> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <
>> > >> > > > > > > vololo100@gmail.com>:
>> > >> > > > > > > > > > >>>>>>
>> > >> > > > > > > > > > >>>>>>> Hi,
>> > >> > > > > > > > > > >>>>>>>
>> > >> > > > > > > > > > >>>>>>> I also think that some warning from IDEA that some code
>> > >> > > > > > > style rule
>> > >> > > > > > > > > > is
>> > >> > > > > > > > > > >>>>>>> violated is a must-have.
>> > >> > > > > > > > > > >>>>>>>
>> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <
>> > >> > > > > > > oignatenko@gridgain.com
>> > >> > > > > > > > > > >:
>> > >> > > > > > > > > > >>>>>>>>
>> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
>> > >> > > > > > > > > > >>>>>>>>
>> > >> > > > > > > > > > >>>>>>>> I believe that whatever style checks we establish at
>> > >> > > > > > > Teamcity, we
>> > >> > > > > > > > > > >>>>> better
>> > >> > > > > > > > > > >>>>>>>> take care of making it easy for developers to find and
>> > >> > > > > fix
>> > >> > > > > > > > > > violations
>> > >> > > > > > > > > > >>>>> in
>> > >> > > > > > > > > > >>>>>>>> their typical dev environment (for Ignite this means, in
>> > >> > > > > > > IDEA). I
>> > >> > > > > > > > > > >>> think
>> > >> > > > > > > > > > >>>>>>> it
>> > >> > > > > > > > > > >>>>>>>> is important that developers can maintain 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 just 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 checkstyle - I
>> > >> > > > > recommend
>> > >> > > > > > > keeping
>> > >> > > > > > > > > > >>> its
>> > >> > > > > > > > > > >>>>>>>> config file somewhere in the project under version
>> > >> > > > > control.
>> > >> > > > > > > I
>> > >> > > > > > > > > > used to
>> > >> > > > > > > > > > >>>>>>>> maintain such a shared style config at one of past jobs
>> > >> > > > > and
>> > >> > > > > > > after
>> > >> > > > > > > > > > >>> some
>> > >> > > > > > > > > > >>>>>>>> experimenting it turned out most convenient to have it
>> > >> > > > > this
>> > >> > > > > > > way -
>> > >> > > > > > > > > > so
>> > >> > > > > > > > > > >>>>> that
>> > >> > > > > > > > > > >>>>>>>> developers could easily assess and discuss style
>> > >> > > > > settings
>> > >> > > > > > > and keep
>> > >> > > > > > > > > > >>>>> track
>> > >> > > > > > > > > > >>>>>>> of
>> > >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka folks 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 community members.
>> > >> > > > > > > Moreover, this
>> > >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we previously
>> > >> > > > > 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 consider the Apache Kafka
>> > >> > > > > > > code
>> > >> > > > > > > > > > style
>> > >> > > > > > > > > > >>> [5]
>> > >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite project a
>> > >> > > > > > > > > > maven-checkstyle-plugin
>> > >> > > > > > > > > > >>>>>>>>> with its own maven profile and run it simultaneously
>> > >> > > > > with
>> > >> > > > > > > other
>> > >> > > > > > > > > > TC.
>> > >> > > > > > > > > > >>> We
>> > >> > > > > > > > > > >>>>>>>>> can also enable the previously configured inspection
>> > >> > > > > > > rules, so no
>> > >> > > > > > > > > > >>>>>>>>> coding style violations will be missed.
>> > >> > > > > > > > > > >>>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>> I see some advantages of using a maven plugin:
>> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
>> > >> > > > > > > > > > >>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
>> > >> > > > > > > > > > >>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
>> > >> > > > > > > > > > >>>>>>>>> [3]
>> > >> > > > > > > > > > >>>>>>>
>> > >> > > > > > > > > > >>>>>
>> > >> > > > > > > > > > >>>
>> > >> > > > > > > > > >
>> > >> > > > > > >
>> > >> > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
>> > >> > > > > > > > > > >>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
>> > >> > > > > > > > > > >>>>>>>>> [5]
>> > >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
>> > >> > > > > > > > > > >>>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
>> > >> > > > > > > > > > >>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>> mr.weider@
>> > >> > > > > > > > > > >>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
>> > >> > > > > > > > > > >>>>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity
>> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
>> > >> > > > > > > > > > >>>>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
>> > >> > > > > > > > > > >>>>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
>> > >> > > > > > > > > > >>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>> mr.weider@
>> > >> > > > > > > > > > >>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
>> > >> > > > > > > > > > >>>>>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
>> > >> > > > > > > > > > >>>>>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
>> > >> > > > > > > > > > >>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>> dpavlov@
>> > >> > > > > > > > > > >>>>>>>>
>> > >> > > > > > > > > > >>>>>>>>> &gt; 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 next 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

Re: Code inspection

[Nikolay Izhikov <ni...@apache.org>]

+1 to enable code style checks in compile time.

We can add option to disable maven codestyle profile with some environment
variable.

Anyone who want violate common project rules in their local branch can set
this variable and write some nasty code before push :)

пт, 15 марта 2019 г., 9:40 Maxim Muzafarov <ma...@gmail.com>:

> 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 build
> stage.
> - increases a bit the build time procedure
> - require additional operations to switch it off for prototyping branches
>
> + do not require TC.Bot visa if someone of the community doesn't use it
> + 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 needs.
>
> ---
>
> 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+Contribute#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, Павлухин Иван <vo...@gmail.com> 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:
> > ====Quoted text====
> > 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.
> > 2. Style check takes some time. With simple checks it is almost
> > negligible. But it can grow if more checks are involved.
> > ====End of quoted text====
> >
> > Some clarifications. 1 is about running from IDEA first. 2 is related
> > to opinions that we should involve much more checks, e.g. using
> > abbreviations.
> >
> > чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> > >
> > > Ivan,
> > >
> > > Let's take a look at all the options we have (ordered by the frequency
> 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
> checkstyle plugin is used in the <build> 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.
> > >
> > > Back to our use cases:
> > >
> > > 1. For checking the ready to merge branches we will fail the ~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.
> > >
> > > 2. For the prototyping branches, you can turn off checkstyle in your
> 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
> checkstyle enabled profile. The common build action as `mvn clean install
> -DskipTests` will activate the profile.
> > >
> > > 4. The checkstyle profile can be disabled explicitly on TC by
> specifying -P !checkstyle option. A don't see any use cases of it, but it's
> completely doable.
> > >
> > > Please, correct me if I've missed something.
> > >
> > > I propose to merge PR [1] as it is, with the configured set of rules.
> > >
> > > [1] https://github.com/apache/ignite/pull/6119
> > >
> > > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com> wrote:
> > >>
> > >> Maxim,
> > >>
> > >> I like an idea of being IDE agnostic. I am ok with currently enabled
> > >> 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 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.
> > >> 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" which I
> > >> think is quite useful.
> > >>
> > >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <ma...@gmail.com>:
> > >> >
> > >> > Ivan,
> > >> >
> > >> > I like that Jetbrains inspections are integrated with IDE and TC 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 with
> code
> > >> > style checking. I've checked popular java projects: hadoop, kafka,
> > >> > spark, hive, netty. All of them are using maven-checkstyle-plugin in
> > >> > their <build> 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 and
> > >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose to
> 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-1018
> > >> > [4]
> https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > >> > [5] http://checkstyle.sourceforge.net/checks.html
> > >> >
> > >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <vo...@gmail.com>
> 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 checkstyle
> > >> > > plugin? Is it integrated into IDEA out of box? As I got it
> additional
> > >> > > 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 visa.
> Visa
> > >> > > includes result from running inspections job.
> > >> > >
> > >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <
> nizhikov@apache.org>:
> > >> > > >
> > >> > > > 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.
> > >> > > >
> > >> > > >
> > >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <
> vololo100@gmail.com>:
> > >> > > >
> > >> > > > > Nikolay,
> > >> > > > >
> > >> > > > > > Should the community spend TC resources for  prototype?
> > >> > > > > Why not? I think it is not bad idea to run all tests against
> 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 with
> other
> > >> > > > > Igniters. I think it is the cheapest way to check the idea
> because the
> > >> > > > > check is fully automated. Requiring a human feedback is much
> 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
> skipping tests
> > >> > > > > execution if inspections detect a problem?
> > >> > > > >
> > >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <
> nizhikov@apache.org>:
> > >> > > > > >
> > >> > > > > > 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
> prototype.
> > >> > > > > >
> > >> > > > > > 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?
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <
> vololo100@gmail.com>:
> > >> > > > > >
> > >> > > > > > > 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
> outline 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 that
> message).
> > >> > > > > > >
> > >> > > > > > > We have a document defining code style which every
> contributor should
> > >> > > > > > > follow [1]. And many points can be checked automatically.
> Personally,
> > >> > > > > > > I do not see much need in writing good javadocs for
> prototype. Why
> > >> > > > > > > should I stub it to be able run any build on TC?
> > >> > > > > > >
> > >> > > > > > > Also, we a have a review process which should be applied
> to every
> > >> > > > > > > patch. Partially it is described in [2]. And due to this
> process every
> > >> > > > > > > patch should not introduce new failures on TC. So, the
> patch should
> > >> > > > > > > not be merged if inspections failed.
> > >> > > > > > >
> > >> > > > > > > P.S. Something more about prototypes and production code.
> There is a
> > >> > > > > > > common bad practice in software engineering. It is
> turning prototypes
> > >> > > > > > > into production code. Often it is much faster to create a
> prototype by
> > >> > > > > > > price of violating some rules of writing "clean code".
> And often
> > >> > > > > > > prototype after successful piloting is turned into
> production code.
> > >> > > > > > > And it is very easy in practice to keep some pieces of
> 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" from
> the beginning.
> > >> > > > > > > So, only ideas are taken from the prototype and a code is
> fully
> > >> > > > > > > rewritten.
> > >> > > > > > >
> > >> > > > > > > [1]
> > >> > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > >> > > > > > > [2]
> > >> > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > >> > > > > > >
> > >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
> maxmuzaf@gmail.com>:
> > >> > > > > > > >
> > >> > > > > > > > Ivan,
> > >> > > > > > > >
> > >> > > > > > > > As the first implementation of this addition, I'd
> prefer to make it
> > >> > > > > > > > working like _Licenses Headers_ suite check. It will
> fail when some
> > >> > > > > of
> > >> > > > > > > > the code style checks violated. Moreover, these
> licenses header
> > >> > > > > checks
> > >> > > > > > > > can be included in the checkstyle plugin configuration.
> > >> > > > > > > >
> > >> > > > > > > > In general, I'd prefer to have a compilation fail error
> with code
> > >> > > > > > > > style checks and after we will get a stable checkstyle
> suite I
> > >> > > > > propose
> > >> > > > > > > > to change it in a "compilation error" way. If we are
> talking about
> > >> > > > > the
> > >> > > > > > > > coding style convenient for most of the community
> members I see no
> > >> > > > > > > > difference with coding sketches or production-ready
> branches equally.
> > >> > > > > > > > Indeed, no one will be against unused imports [or
> spaces 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() == 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 <
> nizhikov@apache.org>
> > >> > > > > > > wrote:
> > >> > > > > > > > >
> > >> > > > > > > > > Actually, I dont see anything wrong with failing
> *compilation*
> > >> > > > > task.
> > >> > > > > > > > >
> > >> > > > > > > > > I think one should use project code style for
> everyday 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?
> > >> > > > > > > > >
> > >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov
> mr.weider@gmail.com:
> > >> > > > > > > > >
> > >> > > > > > > > > > I guess that was about failing build configuration
> with
> > >> > > > > Checkstype,
> > >> > > > > > > not
> > >> > > > > > > > > > compilation build itself.
> > >> > > > > > > > > >
> > >> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <
> vololo100@gmail.com>
> > >> > > > > > > wrote:
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > Folks,
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > Are you going to fail job compiling Ignite
> sources [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 convenient
> to skip some
> > >> > > > > style
> > >> > > > > > > > > > > requirements for such sketches (e.g. well formed
> javadocs).
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > [1]
> > >> > > > > > > > > >
> > >> > > > > > >
> > >> > > > >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <
> > >> > > > > nizhikov@apache.org
> > >> > > > > > > >:
> > >> > > > > > > > > > >>
> > >> > > > > > > > > > >> Petr, we should have 1 configuration for
> project, may be 1
> > >> > > > > > > configuration
> > >> > > > > > > > > > >> per programming language.
> > >> > > > > > > > > > >>
> > >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
> mr.weider@gmail.com:
> > >> > > > > > > > > > >>
> > >> > > > > > > > > > >>> I was asking about how many build configuration
> is intended?
> > >> > > > > One
> > >> > > > > > > for
> > >> > > > > > > > > > all
> > >> > > > > > > > > > >>> and multiple per module?
> > >> > > > > > > > > > >>>
> > >> > > > > > > > > > >>> With IDEA inspections it was going to be build
> 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 build
> task? And each
> > >> > > > > > > module
> > >> > > > > > > > > > builds
> > >> > > > > > > > > > >>>> when it required? If yes, then I propose to
> create a task
> > >> > > > > like
> > >> > > > > > > > > > "Licence
> > >> > > > > > > > > > >>>> check" which will be run for every patch.
> > >> > > > > > > > > > >>>>
> > >> > > > > > > > > > >>>> My point is that violation of codestyle should
> be treated as
> > >> > > > > > > hard as
> > >> > > > > > > > > > >>>> compile error.
> > >> > > > > > > > > > >>>>
> > >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
> mr.weider@gmail.com
> > >> > > > > :
> > >> > > > > > > > > > >>>>
> > >> > > > > > > > > > >>>>> Is build configuration Inspections [Core]
> meant to
> > >> > > > > transform
> > >> > > > > > > into
> > >> > > > > > > > > > single
> > >> > > > > > > > > > >>>>> all-modules check build configuration
> (without module
> > >> > > > > > > subdivision)?
> > >> > > > > > > > > > >>>>>
> > >> > > > > > > > > > >>>>>
> > >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <
> > >> > > > > > > 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/1065-checkstyle-idea
> > >> > > > > > > > > > >>>>>>
> > >> > > > > > > > > > >>>>>> I propose do the following:
> > >> > > > > > > > > > >>>>>>
> > >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules.
> Currently, 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
> Apache Ignite"
> > >> > > > > suite.
> > >> > > > > > > Ignite
> > >> > > > > > > > > > has
> > >> > > > > > > > > > >>>>> to
> > >> > > > > > > > > > >>>>>> fail to build if patch violates codestyle.
> > >> > > > > > > > > > >>>>>>
> > >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <
> > >> > > > > > > vololo100@gmail.com>:
> > >> > > > > > > > > > >>>>>>
> > >> > > > > > > > > > >>>>>>> Hi,
> > >> > > > > > > > > > >>>>>>>
> > >> > > > > > > > > > >>>>>>> I also think that some warning from IDEA
> that some code
> > >> > > > > > > style rule
> > >> > > > > > > > > > is
> > >> > > > > > > > > > >>>>>>> violated is a must-have.
> > >> > > > > > > > > > >>>>>>>
> > >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <
> > >> > > > > > > oignatenko@gridgain.com
> > >> > > > > > > > > > >:
> > >> > > > > > > > > > >>>>>>>>
> > >> > > > > > > > > > >>>>>>>> Hi Maxim,
> > >> > > > > > > > > > >>>>>>>>
> > >> > > > > > > > > > >>>>>>>> I believe that whatever style checks we
> establish at
> > >> > > > > > > Teamcity, we
> > >> > > > > > > > > > >>>>> better
> > >> > > > > > > > > > >>>>>>>> take care of making it easy for developers
> to find and
> > >> > > > > fix
> > >> > > > > > > > > > violations
> > >> > > > > > > > > > >>>>> in
> > >> > > > > > > > > > >>>>>>>> their typical dev environment (for Ignite
> this means, in
> > >> > > > > > > IDEA). I
> > >> > > > > > > > > > >>> think
> > >> > > > > > > > > > >>>>>>> it
> > >> > > > > > > > > > >>>>>>>> is important that developers can maintain
> 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 just
> 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
> checkstyle - I
> > >> > > > > recommend
> > >> > > > > > > keeping
> > >> > > > > > > > > > >>> its
> > >> > > > > > > > > > >>>>>>>> config file somewhere in the project under
> version
> > >> > > > > control.
> > >> > > > > > > I
> > >> > > > > > > > > > used to
> > >> > > > > > > > > > >>>>>>>> maintain such a shared style config at one
> of past jobs
> > >> > > > > and
> > >> > > > > > > after
> > >> > > > > > > > > > >>> some
> > >> > > > > > > > > > >>>>>>>> experimenting it turned out most
> convenient to have it
> > >> > > > > this
> > >> > > > > > > way -
> > >> > > > > > > > > > so
> > >> > > > > > > > > > >>>>> that
> > >> > > > > > > > > > >>>>>>>> developers could easily assess and discuss
> style
> > >> > > > > settings
> > >> > > > > > > and keep
> > >> > > > > > > > > > >>>>> track
> > >> > > > > > > > > > >>>>>>> of
> > >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka folks
> 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 community
> members.
> > >> > > > > > > Moreover, this
> > >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we
> previously
> > >> > > > > 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 consider
> the Apache Kafka
> > >> > > > > > > code
> > >> > > > > > > > > > style
> > >> > > > > > > > > > >>> [5]
> > >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite project a
> > >> > > > > > > > > > maven-checkstyle-plugin
> > >> > > > > > > > > > >>>>>>>>> with its own maven profile and run it
> simultaneously
> > >> > > > > with
> > >> > > > > > > other
> > >> > > > > > > > > > TC.
> > >> > > > > > > > > > >>> We
> > >> > > > > > > > > > >>>>>>>>> can also enable the previously configured
> inspection
> > >> > > > > > > rules, so no
> > >> > > > > > > > > > >>>>>>>>> coding style violations will be missed.
> > >> > > > > > > > > > >>>>>>>>>
> > >> > > > > > > > > > >>>>>>>>> I see some advantages of using a maven
> plugin:
> > >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > >> > > > > > > > > > >>>>>>>>> - can be used with different CI and build
> 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > >> > > > > > > > > > >>>>>>>>> [2]
> https://youtrack.jetbrains.com/issue/TW-58504
> > >> > > > > > > > > > >>>>>>>>> [3]
> > >> > > > > > > > > > >>>>>>>
> > >> > > > > > > > > > >>>>>
> > >> > > > > > > > > > >>>
> > >> > > > > > > > > >
> > >> > > > > > >
> > >> > > > >
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > >> > > > > > > > > > >>>>>>>>> [4]
> https://issues.apache.org/jira/browse/IGNITE-11277
> > >> > > > > > > > > > >>>>>>>>> [5]
> > >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > >> > > > > > > > > > >>>>>>>>>
> > >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov
> &lt;
> > >> > > > > > > > > > >>>>>>>>
> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > >> > > > > > > > > > >>>>>>>>
> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > >> > > > > > > > > > >>>>>>>>>>
> > >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest 2018.2
> TeamCity
> > >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> > >> > > > > > > > > > >>>>>>>>>>
> > >> > > > > > > > > > >>>>>>>>>>
> > >> > > > > > > > > > >>>>>>>>>> [1]
> https://youtrack.jetbrains.com/issue/TW-58504
> > >> > > > > > > > > > >>>>>>>>>>
> > >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov
> &lt;
> > >> > > > > > > > > > >>>>>>>>
> > >> > > > > > > > > > >>>>>>>>> mr.weider@
> > >> > > > > > > > > > >>>>>>>>
> > >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > >> > > > > > > > > > >>>>>>>>>>>
> > >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > >> > > > > > > > > > >>>>>>>>>>>
> > >> > > > > > > > > > >>>>>>>>>>>
> > >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy
> Pavlov &lt;
> > >> > > > > > > > > > >>>>>>>>
> > >> > > > > > > > > > >>>>>>>>> dpavlov@
> > >> > > > > > > > > > >>>>>>>>
> > >> > > > > > > > > > >>>>>>>>> &gt; 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 next
> 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
>
>

Re: Code inspection

[Maxim Muzafarov <ma...@gmail.com>]

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 build stage.
- increases a bit the build time procedure
- require additional operations to switch it off for prototyping branches

+ do not require TC.Bot visa if someone of the community doesn't use it
+ 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 needs.

---

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+Contribute#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, Павлухин Иван <vo...@gmail.com> 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:
> ====Quoted text====
> 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.
> 2. Style check takes some time. With simple checks it is almost
> negligible. But it can grow if more checks are involved.
> ====End of quoted text====
>
> Some clarifications. 1 is about running from IDEA first. 2 is related
> to opinions that we should involve much more checks, e.g. using
> abbreviations.
>
> чт, 7 мар. 2019 г. в 10:36, Maxim Muzafarov <ma...@gmail.com>:
> >
> > Ivan,
> >
> > Let's take a look at all the options we have (ordered by the frequency 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 checkstyle plugin is used in the <build> 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.
> >
> > Back to our use cases:
> >
> > 1. For checking the ready to merge branches we will fail the ~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.
> >
> > 2. For the prototyping branches, you can turn off checkstyle in your 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 checkstyle enabled profile. The common build action as `mvn clean install -DskipTests` will activate the profile.
> >
> > 4. The checkstyle profile can be disabled explicitly on TC by specifying -P !checkstyle option. A don't see any use cases of it, but it's completely doable.
> >
> > Please, correct me if I've missed something.
> >
> > I propose to merge PR [1] as it is, with the configured set of rules.
> >
> > [1] https://github.com/apache/ignite/pull/6119
> >
> > On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com> wrote:
> >>
> >> Maxim,
> >>
> >> I like an idea of being IDE agnostic. I am ok with currently enabled
> >> 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 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.
> >> 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" which I
> >> think is quite useful.
> >>
> >> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <ma...@gmail.com>:
> >> >
> >> > Ivan,
> >> >
> >> > I like that Jetbrains inspections are integrated with IDE and TC 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 with code
> >> > style checking. I've checked popular java projects: hadoop, kafka,
> >> > spark, hive, netty. All of them are using maven-checkstyle-plugin in
> >> > their <build> 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 and
> >> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose to 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-1018
> >> > [4] https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> >> > [5] http://checkstyle.sourceforge.net/checks.html
> >> >
> >> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <vo...@gmail.com> 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 checkstyle
> >> > > plugin? Is it integrated into IDEA out of box? As I got it additional
> >> > > 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 visa. Visa
> >> > > includes result from running inspections job.
> >> > >
> >> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <ni...@apache.org>:
> >> > > >
> >> > > > 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.
> >> > > >
> >> > > >
> >> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <vo...@gmail.com>:
> >> > > >
> >> > > > > Nikolay,
> >> > > > >
> >> > > > > > Should the community spend TC resources for  prototype?
> >> > > > > Why not? I think it is not bad idea to run all tests against 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 with other
> >> > > > > Igniters. I think it is the cheapest way to check the idea because the
> >> > > > > check is fully automated. Requiring a human feedback is much 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 skipping tests
> >> > > > > execution if inspections detect a problem?
> >> > > > >
> >> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <ni...@apache.org>:
> >> > > > > >
> >> > > > > > 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 prototype.
> >> > > > > >
> >> > > > > > 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?
> >> > > > > >
> >> > > > > >
> >> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <vo...@gmail.com>:
> >> > > > > >
> >> > > > > > > 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 outline 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 that message).
> >> > > > > > >
> >> > > > > > > We have a document defining code style which every contributor should
> >> > > > > > > follow [1]. And many points can be checked automatically. Personally,
> >> > > > > > > I do not see much need in writing good javadocs for prototype. Why
> >> > > > > > > should I stub it to be able run any build on TC?
> >> > > > > > >
> >> > > > > > > Also, we a have a review process which should be applied to every
> >> > > > > > > patch. Partially it is described in [2]. And due to this process every
> >> > > > > > > patch should not introduce new failures on TC. So, the patch should
> >> > > > > > > not be merged if inspections failed.
> >> > > > > > >
> >> > > > > > > P.S. Something more about prototypes and production code. There is a
> >> > > > > > > common bad practice in software engineering. It is turning prototypes
> >> > > > > > > into production code. Often it is much faster to create a prototype by
> >> > > > > > > price of violating some rules of writing "clean code". And often
> >> > > > > > > prototype after successful piloting is turned into production code.
> >> > > > > > > And it is very easy in practice to keep some pieces of 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" from the beginning.
> >> > > > > > > So, only ideas are taken from the prototype and a code is fully
> >> > > > > > > rewritten.
> >> > > > > > >
> >> > > > > > > [1]
> >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> >> > > > > > > [2]
> >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> >> > > > > > >
> >> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <ma...@gmail.com>:
> >> > > > > > > >
> >> > > > > > > > Ivan,
> >> > > > > > > >
> >> > > > > > > > As the first implementation of this addition, I'd prefer to make it
> >> > > > > > > > working like _Licenses Headers_ suite check. It will fail when some
> >> > > > > of
> >> > > > > > > > the code style checks violated. Moreover, these licenses header
> >> > > > > checks
> >> > > > > > > > can be included in the checkstyle plugin configuration.
> >> > > > > > > >
> >> > > > > > > > In general, I'd prefer to have a compilation fail error with code
> >> > > > > > > > style checks and after we will get a stable checkstyle suite I
> >> > > > > propose
> >> > > > > > > > to change it in a "compilation error" way. If we are talking about
> >> > > > > the
> >> > > > > > > > coding style convenient for most of the community members I see no
> >> > > > > > > > difference with coding sketches or production-ready branches equally.
> >> > > > > > > > Indeed, no one will be against unused imports [or spaces 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() == 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 <ni...@apache.org>
> >> > > > > > > wrote:
> >> > > > > > > > >
> >> > > > > > > > > Actually, I dont see anything wrong with failing *compilation*
> >> > > > > task.
> >> > > > > > > > >
> >> > > > > > > > > I think one should use project code style for everyday 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?
> >> > > > > > > > >
> >> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.weider@gmail.com:
> >> > > > > > > > >
> >> > > > > > > > > > I guess that was about failing build configuration with
> >> > > > > Checkstype,
> >> > > > > > > not
> >> > > > > > > > > > compilation build itself.
> >> > > > > > > > > >
> >> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <vo...@gmail.com>
> >> > > > > > > wrote:
> >> > > > > > > > > > >
> >> > > > > > > > > > > Folks,
> >> > > > > > > > > > >
> >> > > > > > > > > > > Are you going to fail job compiling Ignite sources [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 convenient to skip some
> >> > > > > style
> >> > > > > > > > > > > requirements for such sketches (e.g. well formed javadocs).
> >> > > > > > > > > > >
> >> > > > > > > > > > > [1]
> >> > > > > > > > > >
> >> > > > > > >
> >> > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> >> > > > > > > > > > >
> >> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <
> >> > > > > nizhikov@apache.org
> >> > > > > > > >:
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> Petr, we should have 1 configuration for project, may be 1
> >> > > > > > > configuration
> >> > > > > > > > > > >> per programming language.
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
> >> > > > > > > > > > >>
> >> > > > > > > > > > >>> I was asking about how many build configuration is intended?
> >> > > > > One
> >> > > > > > > for
> >> > > > > > > > > > all
> >> > > > > > > > > > >>> and multiple per module?
> >> > > > > > > > > > >>>
> >> > > > > > > > > > >>> With IDEA inspections it was going to be build 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 build task? And each
> >> > > > > > > module
> >> > > > > > > > > > builds
> >> > > > > > > > > > >>>> when it required? If yes, then I propose to create a task
> >> > > > > like
> >> > > > > > > > > > "Licence
> >> > > > > > > > > > >>>> check" which will be run for every patch.
> >> > > > > > > > > > >>>>
> >> > > > > > > > > > >>>> My point is that violation of codestyle should be treated as
> >> > > > > > > hard as
> >> > > > > > > > > > >>>> compile error.
> >> > > > > > > > > > >>>>
> >> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com
> >> > > > > :
> >> > > > > > > > > > >>>>
> >> > > > > > > > > > >>>>> Is build configuration Inspections [Core] meant to
> >> > > > > transform
> >> > > > > > > into
> >> > > > > > > > > > single
> >> > > > > > > > > > >>>>> all-modules check build configuration (without module
> >> > > > > > > subdivision)?
> >> > > > > > > > > > >>>>>
> >> > > > > > > > > > >>>>>
> >> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <
> >> > > > > > > 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/1065-checkstyle-idea
> >> > > > > > > > > > >>>>>>
> >> > > > > > > > > > >>>>>> I propose do the following:
> >> > > > > > > > > > >>>>>>
> >> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> >> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite"
> >> > > > > suite.
> >> > > > > > > Ignite
> >> > > > > > > > > > has
> >> > > > > > > > > > >>>>> to
> >> > > > > > > > > > >>>>>> fail to build if patch violates codestyle.
> >> > > > > > > > > > >>>>>>
> >> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <
> >> > > > > > > vololo100@gmail.com>:
> >> > > > > > > > > > >>>>>>
> >> > > > > > > > > > >>>>>>> Hi,
> >> > > > > > > > > > >>>>>>>
> >> > > > > > > > > > >>>>>>> I also think that some warning from IDEA that some code
> >> > > > > > > style rule
> >> > > > > > > > > > is
> >> > > > > > > > > > >>>>>>> violated is a must-have.
> >> > > > > > > > > > >>>>>>>
> >> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <
> >> > > > > > > oignatenko@gridgain.com
> >> > > > > > > > > > >:
> >> > > > > > > > > > >>>>>>>>
> >> > > > > > > > > > >>>>>>>> Hi Maxim,
> >> > > > > > > > > > >>>>>>>>
> >> > > > > > > > > > >>>>>>>> I believe that whatever style checks we establish at
> >> > > > > > > Teamcity, we
> >> > > > > > > > > > >>>>> better
> >> > > > > > > > > > >>>>>>>> take care of making it easy for developers to find and
> >> > > > > fix
> >> > > > > > > > > > violations
> >> > > > > > > > > > >>>>> in
> >> > > > > > > > > > >>>>>>>> their typical dev environment (for Ignite this means, in
> >> > > > > > > IDEA). I
> >> > > > > > > > > > >>> think
> >> > > > > > > > > > >>>>>>> it
> >> > > > > > > > > > >>>>>>>> is important that developers can maintain 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 just 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 checkstyle - I
> >> > > > > recommend
> >> > > > > > > keeping
> >> > > > > > > > > > >>> its
> >> > > > > > > > > > >>>>>>>> config file somewhere in the project under version
> >> > > > > control.
> >> > > > > > > I
> >> > > > > > > > > > used to
> >> > > > > > > > > > >>>>>>>> maintain such a shared style config at one of past jobs
> >> > > > > and
> >> > > > > > > after
> >> > > > > > > > > > >>> some
> >> > > > > > > > > > >>>>>>>> experimenting it turned out most convenient to have it
> >> > > > > this
> >> > > > > > > way -
> >> > > > > > > > > > so
> >> > > > > > > > > > >>>>> that
> >> > > > > > > > > > >>>>>>>> developers could easily assess and discuss style
> >> > > > > settings
> >> > > > > > > and keep
> >> > > > > > > > > > >>>>> track
> >> > > > > > > > > > >>>>>>> of
> >> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka folks 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 community members.
> >> > > > > > > Moreover, this
> >> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we previously
> >> > > > > 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 consider the Apache Kafka
> >> > > > > > > code
> >> > > > > > > > > > style
> >> > > > > > > > > > >>> [5]
> >> > > > > > > > > > >>>>>>>>> way and configure for the Ignite project a
> >> > > > > > > > > > maven-checkstyle-plugin
> >> > > > > > > > > > >>>>>>>>> with its own maven profile and run it simultaneously
> >> > > > > with
> >> > > > > > > other
> >> > > > > > > > > > TC.
> >> > > > > > > > > > >>> We
> >> > > > > > > > > > >>>>>>>>> can also enable the previously configured inspection
> >> > > > > > > rules, so no
> >> > > > > > > > > > >>>>>>>>> coding style violations will be missed.
> >> > > > > > > > > > >>>>>>>>>
> >> > > > > > > > > > >>>>>>>>> I see some advantages of using a maven plugin:
> >> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> >> > > > > > > > > > >>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> >> > > > > > > > > > >>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> >> > > > > > > > > > >>>>>>>>> [3]
> >> > > > > > > > > > >>>>>>>
> >> > > > > > > > > > >>>>>
> >> > > > > > > > > > >>>
> >> > > > > > > > > >
> >> > > > > > >
> >> > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> >> > > > > > > > > > >>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> >> > > > > > > > > > >>>>>>>>> [5]
> >> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> >> > > > > > > > > > >>>>>>>>>
> >> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> >> > > > > > > > > > >>>>>>>>
> >> > > > > > > > > > >>>>>>>>> mr.weider@
> >> > > > > > > > > > >>>>>>>>
> >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> >> > > > > > > > > > >>>>>>>>>>
> >> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity
> >> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> >> > > > > > > > > > >>>>>>>>>>
> >> > > > > > > > > > >>>>>>>>>>
> >> > > > > > > > > > >>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> >> > > > > > > > > > >>>>>>>>>>
> >> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> >> > > > > > > > > > >>>>>>>>
> >> > > > > > > > > > >>>>>>>>> mr.weider@
> >> > > > > > > > > > >>>>>>>>
> >> > > > > > > > > > >>>>>>>>> &gt; wrote:
> >> > > > > > > > > > >>>>>>>>>>>
> >> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> >> > > > > > > > > > >>>>>>>>>>>
> >> > > > > > > > > > >>>>>>>>>>>
> >> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> >> > > > > > > > > > >>>>>>>>
> >> > > > > > > > > > >>>>>>>>> dpavlov@
> >> > > > > > > > > > >>>>>>>>
> >> > > > > > > > > > >>>>>>>>> &gt; 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 next 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

Re: Code inspection

[Maxim Muzafarov <ma...@gmail.com>]

Ivan,

Let's take a look at all the options we have (ordered by the frequency 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 checkstyle
plugin is used in the <build> 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.

Back to our use cases:

1. For checking the ready to merge branches we will fail the ~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.

2. For the prototyping branches, you can turn off checkstyle in your 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 checkstyle
enabled profile. The common build action as `mvn clean install -DskipTests`
will activate the profile.

4. The checkstyle profile can be disabled explicitly on TC by specifying -P
!checkstyle option. A don't see any use cases of it, but it's completely
doable.

Please, correct me if I've missed something.

I propose to merge PR [1] as it is, with the configured set of rules.

[1] https://github.com/apache/ignite/pull/6119

On Tue, 5 Mar 2019 at 19:02 Павлухин Иван <vo...@gmail.com> wrote:

> Maxim,
>
> I like an idea of being IDE agnostic. I am ok with currently enabled
> 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 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.
> 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" which I
> think is quite useful.
>
> пн, 4 мар. 2019 г. в 15:00, Maxim Muzafarov <ma...@gmail.com>:
> >
> > Ivan,
> >
> > I like that Jetbrains inspections are integrated with IDE and TC 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 with code
> > style checking. I've checked popular java projects: hadoop, kafka,
> > spark, hive, netty. All of them are using maven-checkstyle-plugin in
> > their <build> 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 and
> > SizeReplaceableByIsEmpty (all code style checks [5]). Propose to 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-1018
> > [4]
> https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
> > [5] http://checkstyle.sourceforge.net/checks.html
> >
> > On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <vo...@gmail.com> 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 checkstyle
> > > plugin? Is it integrated into IDEA out of box? As I got it additional
> > > 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 visa. Visa
> > > includes result from running inspections job.
> > >
> > > чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <ni...@apache.org>:
> > > >
> > > > 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.
> > > >
> > > >
> > > > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <vo...@gmail.com>:
> > > >
> > > > > Nikolay,
> > > > >
> > > > > > Should the community spend TC resources for  prototype?
> > > > > Why not? I think it is not bad idea to run all tests against 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 with other
> > > > > Igniters. I think it is the cheapest way to check the idea because
> the
> > > > > check is fully automated. Requiring a human feedback is much 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 skipping
> tests
> > > > > execution if inspections detect a problem?
> > > > >
> > > > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <nizhikov@apache.org
> >:
> > > > > >
> > > > > > 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 prototype.
> > > > > >
> > > > > > 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?
> > > > > >
> > > > > >
> > > > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <vololo100@gmail.com
> >:
> > > > > >
> > > > > > > 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 outline
> 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 that
> message).
> > > > > > >
> > > > > > > We have a document defining code style which every contributor
> should
> > > > > > > follow [1]. And many points can be checked automatically.
> Personally,
> > > > > > > I do not see much need in writing good javadocs for prototype.
> Why
> > > > > > > should I stub it to be able run any build on TC?
> > > > > > >
> > > > > > > Also, we a have a review process which should be applied to
> every
> > > > > > > patch. Partially it is described in [2]. And due to this
> process every
> > > > > > > patch should not introduce new failures on TC. So, the patch
> should
> > > > > > > not be merged if inspections failed.
> > > > > > >
> > > > > > > P.S. Something more about prototypes and production code.
> There is a
> > > > > > > common bad practice in software engineering. It is turning
> prototypes
> > > > > > > into production code. Often it is much faster to create a
> prototype by
> > > > > > > price of violating some rules of writing "clean code". And
> often
> > > > > > > prototype after successful piloting is turned into production
> code.
> > > > > > > And it is very easy in practice to keep some pieces of
> 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" from the
> beginning.
> > > > > > > So, only ideas are taken from the prototype and a code is fully
> > > > > > > rewritten.
> > > > > > >
> > > > > > > [1]
> > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > > > > [2]
> > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > > > >
> > > > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <
> maxmuzaf@gmail.com>:
> > > > > > > >
> > > > > > > > Ivan,
> > > > > > > >
> > > > > > > > As the first implementation of this addition, I'd prefer to
> make it
> > > > > > > > working like _Licenses Headers_ suite check. It will fail
> when some
> > > > > of
> > > > > > > > the code style checks violated. Moreover, these licenses
> header
> > > > > checks
> > > > > > > > can be included in the checkstyle plugin configuration.
> > > > > > > >
> > > > > > > > In general, I'd prefer to have a compilation fail error with
> code
> > > > > > > > style checks and after we will get a stable checkstyle suite
> I
> > > > > propose
> > > > > > > > to change it in a "compilation error" way. If we are talking
> about
> > > > > the
> > > > > > > > coding style convenient for most of the community members I
> see no
> > > > > > > > difference with coding sketches or production-ready branches
> equally.
> > > > > > > > Indeed, no one will be against unused imports [or spaces
> 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() == 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 <
> nizhikov@apache.org>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Actually, I dont see anything wrong with failing
> *compilation*
> > > > > task.
> > > > > > > > >
> > > > > > > > > I think one should use project code style for everyday
> 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?
> > > > > > > > >
> > > > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov
> mr.weider@gmail.com:
> > > > > > > > >
> > > > > > > > > > I guess that was about failing build configuration with
> > > > > Checkstype,
> > > > > > > not
> > > > > > > > > > compilation build itself.
> > > > > > > > > >
> > > > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <
> vololo100@gmail.com>
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Folks,
> > > > > > > > > > >
> > > > > > > > > > > Are you going to fail job compiling Ignite sources [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 convenient to
> skip some
> > > > > style
> > > > > > > > > > > requirements for such sketches (e.g. well formed
> javadocs).
> > > > > > > > > > >
> > > > > > > > > > > [1]
> > > > > > > > > >
> > > > > > >
> > > > >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > > > > > > >
> > > > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <
> > > > > nizhikov@apache.org
> > > > > > > >:
> > > > > > > > > > >>
> > > > > > > > > > >> Petr, we should have 1 configuration for project, may
> be 1
> > > > > > > configuration
> > > > > > > > > > >> per programming language.
> > > > > > > > > > >>
> > > > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov
> mr.weider@gmail.com:
> > > > > > > > > > >>
> > > > > > > > > > >>> I was asking about how many build configuration is
> intended?
> > > > > One
> > > > > > > for
> > > > > > > > > > all
> > > > > > > > > > >>> and multiple per module?
> > > > > > > > > > >>>
> > > > > > > > > > >>> With IDEA inspections it was going to be build
> 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 build task?
> And each
> > > > > > > module
> > > > > > > > > > builds
> > > > > > > > > > >>>> when it required? If yes, then I propose to create
> a task
> > > > > like
> > > > > > > > > > "Licence
> > > > > > > > > > >>>> check" which will be run for every patch.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> My point is that violation of codestyle should be
> treated as
> > > > > > > hard as
> > > > > > > > > > >>>> compile error.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov
> mr.weider@gmail.com
> > > > > :
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>> Is build configuration Inspections [Core] meant to
> > > > > transform
> > > > > > > into
> > > > > > > > > > single
> > > > > > > > > > >>>>> all-modules check build configuration (without
> module
> > > > > > > subdivision)?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <
> > > > > > > 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/1065-checkstyle-idea
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> I propose do the following:
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > > > > > > > > >>>>>> 2. Apply checks to all Ignite modules. Currently,
> 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 Apache
> Ignite"
> > > > > suite.
> > > > > > > Ignite
> > > > > > > > > > has
> > > > > > > > > > >>>>> to
> > > > > > > > > > >>>>>> fail to build if patch violates codestyle.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <
> > > > > > > vololo100@gmail.com>:
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>> Hi,
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>> I also think that some warning from IDEA that
> some code
> > > > > > > style rule
> > > > > > > > > > is
> > > > > > > > > > >>>>>>> violated is a must-have.
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <
> > > > > > > oignatenko@gridgain.com
> > > > > > > > > > >:
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>> Hi Maxim,
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>> I believe that whatever style checks we
> establish at
> > > > > > > Teamcity, we
> > > > > > > > > > >>>>> better
> > > > > > > > > > >>>>>>>> take care of making it easy for developers to
> find and
> > > > > fix
> > > > > > > > > > violations
> > > > > > > > > > >>>>> in
> > > > > > > > > > >>>>>>>> their typical dev environment (for Ignite this
> means, in
> > > > > > > IDEA). I
> > > > > > > > > > >>> think
> > > > > > > > > > >>>>>>> it
> > > > > > > > > > >>>>>>>> is important that developers can maintain
> 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 just 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 checkstyle - I
> > > > > recommend
> > > > > > > keeping
> > > > > > > > > > >>> its
> > > > > > > > > > >>>>>>>> config file somewhere in the project under
> version
> > > > > control.
> > > > > > > I
> > > > > > > > > > used to
> > > > > > > > > > >>>>>>>> maintain such a shared style config at one of
> past jobs
> > > > > and
> > > > > > > after
> > > > > > > > > > >>> some
> > > > > > > > > > >>>>>>>> experimenting it turned out most convenient to
> have it
> > > > > this
> > > > > > > way -
> > > > > > > > > > so
> > > > > > > > > > >>>>> that
> > > > > > > > > > >>>>>>>> developers could easily assess and discuss style
> > > > > settings
> > > > > > > and keep
> > > > > > > > > > >>>>> track
> > > > > > > > > > >>>>>>> of
> > > > > > > > > > >>>>>>>> changes in these. (note how Kafka folks 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 community
> members.
> > > > > > > Moreover, this
> > > > > > > > > > >>>>>>>>> suite is no longer checks rules we previously
> > > > > 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 consider the
> Apache Kafka
> > > > > > > code
> > > > > > > > > > style
> > > > > > > > > > >>> [5]
> > > > > > > > > > >>>>>>>>> way and configure for the Ignite project a
> > > > > > > > > > maven-checkstyle-plugin
> > > > > > > > > > >>>>>>>>> with its own maven profile and run it
> simultaneously
> > > > > with
> > > > > > > other
> > > > > > > > > > TC.
> > > > > > > > > > >>> We
> > > > > > > > > > >>>>>>>>> can also enable the previously configured
> inspection
> > > > > > > rules, so no
> > > > > > > > > > >>>>>>>>> coding style violations will be missed.
> > > > > > > > > > >>>>>>>>>
> > > > > > > > > > >>>>>>>>> I see some advantages of using a maven plugin:
> > > > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > > > > > > > > >>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > > > > > > >>>>>>>>> [2]
> https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > > > >>>>>>>>> [3]
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>
> > > > > > > > > >
> > > > > > >
> > > > >
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > > > > > > >>>>>>>>> [4]
> https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > > > > > >>>>>>>>> [5]
> > > > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > > > > > > >>>>>>>>>
> > > > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >>>>>>>>>> It seems there is bug in latest 2018.2
> TeamCity
> > > > > > > > > > >>>>>>>>>> Bug is filed [1]
> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >>>>>>>>>> [1]
> https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>>> mr.weider@
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov
> &lt;
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>>> dpavlov@
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>>> &gt; 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 next 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

Re: Code inspection

[Maxim Muzafarov <ma...@gmail.com>]

Ivan,

I like that Jetbrains inspections are integrated with IDE and TC 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 with code
style checking. I've checked popular java projects: hadoop, kafka,
spark, hive, netty. All of them are using maven-checkstyle-plugin in
their <build> 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 and
SizeReplaceableByIsEmpty (all code style checks [5]). Propose to 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-1018
[4] https://issues.apache.org/jira/browse/IGNITE-11277?focusedCommentId=16771200&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771200
[5] http://checkstyle.sourceforge.net/checks.html

On Thu, 14 Feb 2019 at 16:21, Павлухин Иван <vo...@gmail.com> 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 checkstyle
> plugin? Is it integrated into IDEA out of box? As I got it additional
> 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 visa. Visa
> includes result from running inspections job.
>
> чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <ni...@apache.org>:
> >
> > 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.
> >
> >
> > чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <vo...@gmail.com>:
> >
> > > Nikolay,
> > >
> > > > Should the community spend TC resources for  prototype?
> > > Why not? I think it is not bad idea to run all tests against 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 with other
> > > Igniters. I think it is the cheapest way to check the idea because the
> > > check is fully automated. Requiring a human feedback is much 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 skipping tests
> > > execution if inspections detect a problem?
> > >
> > > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <ni...@apache.org>:
> > > >
> > > > 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 prototype.
> > > >
> > > > 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?
> > > >
> > > >
> > > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <vo...@gmail.com>:
> > > >
> > > > > 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 outline 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 that message).
> > > > >
> > > > > We have a document defining code style which every contributor should
> > > > > follow [1]. And many points can be checked automatically. Personally,
> > > > > I do not see much need in writing good javadocs for prototype. Why
> > > > > should I stub it to be able run any build on TC?
> > > > >
> > > > > Also, we a have a review process which should be applied to every
> > > > > patch. Partially it is described in [2]. And due to this process every
> > > > > patch should not introduce new failures on TC. So, the patch should
> > > > > not be merged if inspections failed.
> > > > >
> > > > > P.S. Something more about prototypes and production code. There is a
> > > > > common bad practice in software engineering. It is turning prototypes
> > > > > into production code. Often it is much faster to create a prototype by
> > > > > price of violating some rules of writing "clean code". And often
> > > > > prototype after successful piloting is turned into production code.
> > > > > And it is very easy in practice to keep some pieces of 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" from the beginning.
> > > > > So, only ideas are taken from the prototype and a code is fully
> > > > > rewritten.
> > > > >
> > > > > [1]
> > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > > [2]
> > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > >
> > > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <ma...@gmail.com>:
> > > > > >
> > > > > > Ivan,
> > > > > >
> > > > > > As the first implementation of this addition, I'd prefer to make it
> > > > > > working like _Licenses Headers_ suite check. It will fail when some
> > > of
> > > > > > the code style checks violated. Moreover, these licenses header
> > > checks
> > > > > > can be included in the checkstyle plugin configuration.
> > > > > >
> > > > > > In general, I'd prefer to have a compilation fail error with code
> > > > > > style checks and after we will get a stable checkstyle suite I
> > > propose
> > > > > > to change it in a "compilation error" way. If we are talking about
> > > the
> > > > > > coding style convenient for most of the community members I see no
> > > > > > difference with coding sketches or production-ready branches equally.
> > > > > > Indeed, no one will be against unused imports [or spaces 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() == 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 <ni...@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > Actually, I dont see anything wrong with failing *compilation*
> > > task.
> > > > > > >
> > > > > > > I think one should use project code style for everyday 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?
> > > > > > >
> > > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.weider@gmail.com:
> > > > > > >
> > > > > > > > I guess that was about failing build configuration with
> > > Checkstype,
> > > > > not
> > > > > > > > compilation build itself.
> > > > > > > >
> > > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <vo...@gmail.com>
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > Folks,
> > > > > > > > >
> > > > > > > > > Are you going to fail job compiling Ignite sources [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 convenient to skip some
> > > style
> > > > > > > > > requirements for such sketches (e.g. well formed javadocs).
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > >
> > > > >
> > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > > > > >
> > > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <
> > > nizhikov@apache.org
> > > > > >:
> > > > > > > > >>
> > > > > > > > >> Petr, we should have 1 configuration for project, may be 1
> > > > > configuration
> > > > > > > > >> per programming language.
> > > > > > > > >>
> > > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
> > > > > > > > >>
> > > > > > > > >>> I was asking about how many build configuration is intended?
> > > One
> > > > > for
> > > > > > > > all
> > > > > > > > >>> and multiple per module?
> > > > > > > > >>>
> > > > > > > > >>> With IDEA inspections it was going to be build 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 build task? And each
> > > > > module
> > > > > > > > builds
> > > > > > > > >>>> when it required? If yes, then I propose to create a task
> > > like
> > > > > > > > "Licence
> > > > > > > > >>>> check" which will be run for every patch.
> > > > > > > > >>>>
> > > > > > > > >>>> My point is that violation of codestyle should be treated as
> > > > > hard as
> > > > > > > > >>>> compile error.
> > > > > > > > >>>>
> > > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com
> > > :
> > > > > > > > >>>>
> > > > > > > > >>>>> Is build configuration Inspections [Core] meant to
> > > transform
> > > > > into
> > > > > > > > single
> > > > > > > > >>>>> all-modules check build configuration (without module
> > > > > subdivision)?
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <
> > > > > 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/1065-checkstyle-idea
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> I propose do the following:
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > > > > > > >>>>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite"
> > > suite.
> > > > > Ignite
> > > > > > > > has
> > > > > > > > >>>>> to
> > > > > > > > >>>>>> fail to build if patch violates codestyle.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <
> > > > > vololo100@gmail.com>:
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>> Hi,
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>> I also think that some warning from IDEA that some code
> > > > > style rule
> > > > > > > > is
> > > > > > > > >>>>>>> violated is a must-have.
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <
> > > > > oignatenko@gridgain.com
> > > > > > > > >:
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> Hi Maxim,
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> I believe that whatever style checks we establish at
> > > > > Teamcity, we
> > > > > > > > >>>>> better
> > > > > > > > >>>>>>>> take care of making it easy for developers to find and
> > > fix
> > > > > > > > violations
> > > > > > > > >>>>> in
> > > > > > > > >>>>>>>> their typical dev environment (for Ignite this means, in
> > > > > IDEA). I
> > > > > > > > >>> think
> > > > > > > > >>>>>>> it
> > > > > > > > >>>>>>>> is important that developers can maintain 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 just 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 checkstyle - I
> > > recommend
> > > > > keeping
> > > > > > > > >>> its
> > > > > > > > >>>>>>>> config file somewhere in the project under version
> > > control.
> > > > > I
> > > > > > > > used to
> > > > > > > > >>>>>>>> maintain such a shared style config at one of past jobs
> > > and
> > > > > after
> > > > > > > > >>> some
> > > > > > > > >>>>>>>> experimenting it turned out most convenient to have it
> > > this
> > > > > way -
> > > > > > > > so
> > > > > > > > >>>>> that
> > > > > > > > >>>>>>>> developers could easily assess and discuss style
> > > settings
> > > > > and keep
> > > > > > > > >>>>> track
> > > > > > > > >>>>>>> of
> > > > > > > > >>>>>>>> changes in these. (note how Kafka folks 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 community members.
> > > > > Moreover, this
> > > > > > > > >>>>>>>>> suite is no longer checks rules we previously
> > > 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 consider the Apache Kafka
> > > > > code
> > > > > > > > style
> > > > > > > > >>> [5]
> > > > > > > > >>>>>>>>> way and configure for the Ignite project a
> > > > > > > > maven-checkstyle-plugin
> > > > > > > > >>>>>>>>> with its own maven profile and run it simultaneously
> > > with
> > > > > other
> > > > > > > > TC.
> > > > > > > > >>> We
> > > > > > > > >>>>>>>>> can also enable the previously configured inspection
> > > > > rules, so no
> > > > > > > > >>>>>>>>> coding style violations will be missed.
> > > > > > > > >>>>>>>>>
> > > > > > > > >>>>>>>>> I see some advantages of using a maven plugin:
> > > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > > > > > > >>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > > > > >>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > >>>>>>>>> [3]
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>
> > > > > > > >
> > > > >
> > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > > > > >>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > > > >>>>>>>>> [5]
> > > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > > > > >>>>>>>>>
> > > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>> mr.weider@
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > > >>>>>>>>>>
> > > > > > > > >>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity
> > > > > > > > >>>>>>>>>> Bug is filed [1]
> > > > > > > > >>>>>>>>>>
> > > > > > > > >>>>>>>>>>
> > > > > > > > >>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > > >>>>>>>>>>
> > > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>> mr.weider@
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > > >>>>>>>>>>>
> > > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > > > > > > > >>>>>>>>>>>
> > > > > > > > >>>>>>>>>>>
> > > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>> dpavlov@
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>> &gt; 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 next 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

Re: Code inspection

[Павлухин Иван <vo...@gmail.com>]

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 checkstyle
plugin? Is it integrated into IDEA out of box? As I got it additional
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 visa. Visa
includes result from running inspections job.

чт, 14 февр. 2019 г. в 16:08, Nikolay Izhikov <ni...@apache.org>:
>
> 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.
>
>
> чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <vo...@gmail.com>:
>
> > Nikolay,
> >
> > > Should the community spend TC resources for  prototype?
> > Why not? I think it is not bad idea to run all tests against 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 with other
> > Igniters. I think it is the cheapest way to check the idea because the
> > check is fully automated. Requiring a human feedback is much 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 skipping tests
> > execution if inspections detect a problem?
> >
> > чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <ni...@apache.org>:
> > >
> > > 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 prototype.
> > >
> > > 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?
> > >
> > >
> > > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <vo...@gmail.com>:
> > >
> > > > 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 outline 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 that message).
> > > >
> > > > We have a document defining code style which every contributor should
> > > > follow [1]. And many points can be checked automatically. Personally,
> > > > I do not see much need in writing good javadocs for prototype. Why
> > > > should I stub it to be able run any build on TC?
> > > >
> > > > Also, we a have a review process which should be applied to every
> > > > patch. Partially it is described in [2]. And due to this process every
> > > > patch should not introduce new failures on TC. So, the patch should
> > > > not be merged if inspections failed.
> > > >
> > > > P.S. Something more about prototypes and production code. There is a
> > > > common bad practice in software engineering. It is turning prototypes
> > > > into production code. Often it is much faster to create a prototype by
> > > > price of violating some rules of writing "clean code". And often
> > > > prototype after successful piloting is turned into production code.
> > > > And it is very easy in practice to keep some pieces of 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" from the beginning.
> > > > So, only ideas are taken from the prototype and a code is fully
> > > > rewritten.
> > > >
> > > > [1]
> > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > > [2]
> > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > >
> > > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <ma...@gmail.com>:
> > > > >
> > > > > Ivan,
> > > > >
> > > > > As the first implementation of this addition, I'd prefer to make it
> > > > > working like _Licenses Headers_ suite check. It will fail when some
> > of
> > > > > the code style checks violated. Moreover, these licenses header
> > checks
> > > > > can be included in the checkstyle plugin configuration.
> > > > >
> > > > > In general, I'd prefer to have a compilation fail error with code
> > > > > style checks and after we will get a stable checkstyle suite I
> > propose
> > > > > to change it in a "compilation error" way. If we are talking about
> > the
> > > > > coding style convenient for most of the community members I see no
> > > > > difference with coding sketches or production-ready branches equally.
> > > > > Indeed, no one will be against unused imports [or spaces 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() == 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 <ni...@apache.org>
> > > > wrote:
> > > > > >
> > > > > > Actually, I dont see anything wrong with failing *compilation*
> > task.
> > > > > >
> > > > > > I think one should use project code style for everyday 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?
> > > > > >
> > > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.weider@gmail.com:
> > > > > >
> > > > > > > I guess that was about failing build configuration with
> > Checkstype,
> > > > not
> > > > > > > compilation build itself.
> > > > > > >
> > > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <vo...@gmail.com>
> > > > wrote:
> > > > > > > >
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > > Are you going to fail job compiling Ignite sources [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 convenient to skip some
> > style
> > > > > > > > requirements for such sketches (e.g. well formed javadocs).
> > > > > > > >
> > > > > > > > [1]
> > > > > > >
> > > >
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > > > >
> > > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <
> > nizhikov@apache.org
> > > > >:
> > > > > > > >>
> > > > > > > >> Petr, we should have 1 configuration for project, may be 1
> > > > configuration
> > > > > > > >> per programming language.
> > > > > > > >>
> > > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
> > > > > > > >>
> > > > > > > >>> I was asking about how many build configuration is intended?
> > One
> > > > for
> > > > > > > all
> > > > > > > >>> and multiple per module?
> > > > > > > >>>
> > > > > > > >>> With IDEA inspections it was going to be build 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 build task? And each
> > > > module
> > > > > > > builds
> > > > > > > >>>> when it required? If yes, then I propose to create a task
> > like
> > > > > > > "Licence
> > > > > > > >>>> check" which will be run for every patch.
> > > > > > > >>>>
> > > > > > > >>>> My point is that violation of codestyle should be treated as
> > > > hard as
> > > > > > > >>>> compile error.
> > > > > > > >>>>
> > > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com
> > :
> > > > > > > >>>>
> > > > > > > >>>>> Is build configuration Inspections [Core] meant to
> > transform
> > > > into
> > > > > > > single
> > > > > > > >>>>> all-modules check build configuration (without module
> > > > subdivision)?
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <
> > > > 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/1065-checkstyle-idea
> > > > > > > >>>>>>
> > > > > > > >>>>>> I propose do the following:
> > > > > > > >>>>>>
> > > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > > > > > >>>>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite"
> > suite.
> > > > Ignite
> > > > > > > has
> > > > > > > >>>>> to
> > > > > > > >>>>>> fail to build if patch violates codestyle.
> > > > > > > >>>>>>
> > > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <
> > > > vololo100@gmail.com>:
> > > > > > > >>>>>>
> > > > > > > >>>>>>> Hi,
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> I also think that some warning from IDEA that some code
> > > > style rule
> > > > > > > is
> > > > > > > >>>>>>> violated is a must-have.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <
> > > > oignatenko@gridgain.com
> > > > > > > >:
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> Hi Maxim,
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> I believe that whatever style checks we establish at
> > > > Teamcity, we
> > > > > > > >>>>> better
> > > > > > > >>>>>>>> take care of making it easy for developers to find and
> > fix
> > > > > > > violations
> > > > > > > >>>>> in
> > > > > > > >>>>>>>> their typical dev environment (for Ignite this means, in
> > > > IDEA). I
> > > > > > > >>> think
> > > > > > > >>>>>>> it
> > > > > > > >>>>>>>> is important that developers can maintain 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 just 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 checkstyle - I
> > recommend
> > > > keeping
> > > > > > > >>> its
> > > > > > > >>>>>>>> config file somewhere in the project under version
> > control.
> > > > I
> > > > > > > used to
> > > > > > > >>>>>>>> maintain such a shared style config at one of past jobs
> > and
> > > > after
> > > > > > > >>> some
> > > > > > > >>>>>>>> experimenting it turned out most convenient to have it
> > this
> > > > way -
> > > > > > > so
> > > > > > > >>>>> that
> > > > > > > >>>>>>>> developers could easily assess and discuss style
> > settings
> > > > and keep
> > > > > > > >>>>> track
> > > > > > > >>>>>>> of
> > > > > > > >>>>>>>> changes in these. (note how Kafka folks 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 community members.
> > > > Moreover, this
> > > > > > > >>>>>>>>> suite is no longer checks rules we previously
> > 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 consider the Apache Kafka
> > > > code
> > > > > > > style
> > > > > > > >>> [5]
> > > > > > > >>>>>>>>> way and configure for the Ignite project a
> > > > > > > maven-checkstyle-plugin
> > > > > > > >>>>>>>>> with its own maven profile and run it simultaneously
> > with
> > > > other
> > > > > > > TC.
> > > > > > > >>> We
> > > > > > > >>>>>>>>> can also enable the previously configured inspection
> > > > rules, so no
> > > > > > > >>>>>>>>> coding style violations will be missed.
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>> I see some advantages of using a maven plugin:
> > > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > > > > > >>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > > > >>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > >>>>>>>>> [3]
> > > > > > > >>>>>>>
> > > > > > > >>>>>
> > > > > > > >>>
> > > > > > >
> > > >
> > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > > > >>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > > >>>>>>>>> [5]
> > https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>> mr.weider@
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity
> > > > > > > >>>>>>>>>> Bug is filed [1]
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>> mr.weider@
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>> &gt; wrote:
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>> dpavlov@
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>> &gt; 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 next 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

Re: Code inspection

[Nikolay Izhikov <ni...@apache.org>]

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.


чт, 14 февр. 2019 г. в 15:21, Павлухин Иван <vo...@gmail.com>:

> Nikolay,
>
> > Should the community spend TC resources for  prototype?
> Why not? I think it is not bad idea to run all tests against 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 with other
> Igniters. I think it is the cheapest way to check the idea because the
> check is fully automated. Requiring a human feedback is much 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 skipping tests
> execution if inspections detect a problem?
>
> чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <ni...@apache.org>:
> >
> > 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 prototype.
> >
> > 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?
> >
> >
> > ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <vo...@gmail.com>:
> >
> > > 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 outline 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 that message).
> > >
> > > We have a document defining code style which every contributor should
> > > follow [1]. And many points can be checked automatically. Personally,
> > > I do not see much need in writing good javadocs for prototype. Why
> > > should I stub it to be able run any build on TC?
> > >
> > > Also, we a have a review process which should be applied to every
> > > patch. Partially it is described in [2]. And due to this process every
> > > patch should not introduce new failures on TC. So, the patch should
> > > not be merged if inspections failed.
> > >
> > > P.S. Something more about prototypes and production code. There is a
> > > common bad practice in software engineering. It is turning prototypes
> > > into production code. Often it is much faster to create a prototype by
> > > price of violating some rules of writing "clean code". And often
> > > prototype after successful piloting is turned into production code.
> > > And it is very easy in practice to keep some pieces of 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" from the beginning.
> > > So, only ideas are taken from the prototype and a code is fully
> > > rewritten.
> > >
> > > [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > [2]
> https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > >
> > > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <ma...@gmail.com>:
> > > >
> > > > Ivan,
> > > >
> > > > As the first implementation of this addition, I'd prefer to make it
> > > > working like _Licenses Headers_ suite check. It will fail when some
> of
> > > > the code style checks violated. Moreover, these licenses header
> checks
> > > > can be included in the checkstyle plugin configuration.
> > > >
> > > > In general, I'd prefer to have a compilation fail error with code
> > > > style checks and after we will get a stable checkstyle suite I
> propose
> > > > to change it in a "compilation error" way. If we are talking about
> the
> > > > coding style convenient for most of the community members I see no
> > > > difference with coding sketches or production-ready branches equally.
> > > > Indeed, no one will be against unused imports [or spaces 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() == 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 <ni...@apache.org>
> > > wrote:
> > > > >
> > > > > Actually, I dont see anything wrong with failing *compilation*
> task.
> > > > >
> > > > > I think one should use project code style for everyday 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?
> > > > >
> > > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.weider@gmail.com:
> > > > >
> > > > > > I guess that was about failing build configuration with
> Checkstype,
> > > not
> > > > > > compilation build itself.
> > > > > >
> > > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <vo...@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > Folks,
> > > > > > >
> > > > > > > Are you going to fail job compiling Ignite sources [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 convenient to skip some
> style
> > > > > > > requirements for such sketches (e.g. well formed javadocs).
> > > > > > >
> > > > > > > [1]
> > > > > >
> > >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > > >
> > > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <
> nizhikov@apache.org
> > > >:
> > > > > > >>
> > > > > > >> Petr, we should have 1 configuration for project, may be 1
> > > configuration
> > > > > > >> per programming language.
> > > > > > >>
> > > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
> > > > > > >>
> > > > > > >>> I was asking about how many build configuration is intended?
> One
> > > for
> > > > > > all
> > > > > > >>> and multiple per module?
> > > > > > >>>
> > > > > > >>> With IDEA inspections it was going to be build 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 build task? And each
> > > module
> > > > > > builds
> > > > > > >>>> when it required? If yes, then I propose to create a task
> like
> > > > > > "Licence
> > > > > > >>>> check" which will be run for every patch.
> > > > > > >>>>
> > > > > > >>>> My point is that violation of codestyle should be treated as
> > > hard as
> > > > > > >>>> compile error.
> > > > > > >>>>
> > > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com
> :
> > > > > > >>>>
> > > > > > >>>>> Is build configuration Inspections [Core] meant to
> transform
> > > into
> > > > > > single
> > > > > > >>>>> all-modules check build configuration (without module
> > > subdivision)?
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <
> > > 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/1065-checkstyle-idea
> > > > > > >>>>>>
> > > > > > >>>>>> I propose do the following:
> > > > > > >>>>>>
> > > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > > > > >>>>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite"
> suite.
> > > Ignite
> > > > > > has
> > > > > > >>>>> to
> > > > > > >>>>>> fail to build if patch violates codestyle.
> > > > > > >>>>>>
> > > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <
> > > vololo100@gmail.com>:
> > > > > > >>>>>>
> > > > > > >>>>>>> Hi,
> > > > > > >>>>>>>
> > > > > > >>>>>>> I also think that some warning from IDEA that some code
> > > style rule
> > > > > > is
> > > > > > >>>>>>> violated is a must-have.
> > > > > > >>>>>>>
> > > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <
> > > oignatenko@gridgain.com
> > > > > > >:
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Hi Maxim,
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> I believe that whatever style checks we establish at
> > > Teamcity, we
> > > > > > >>>>> better
> > > > > > >>>>>>>> take care of making it easy for developers to find and
> fix
> > > > > > violations
> > > > > > >>>>> in
> > > > > > >>>>>>>> their typical dev environment (for Ignite this means, in
> > > IDEA). I
> > > > > > >>> think
> > > > > > >>>>>>> it
> > > > > > >>>>>>>> is important that developers can maintain 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 just 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 checkstyle - I
> recommend
> > > keeping
> > > > > > >>> its
> > > > > > >>>>>>>> config file somewhere in the project under version
> control.
> > > I
> > > > > > used to
> > > > > > >>>>>>>> maintain such a shared style config at one of past jobs
> and
> > > after
> > > > > > >>> some
> > > > > > >>>>>>>> experimenting it turned out most convenient to have it
> this
> > > way -
> > > > > > so
> > > > > > >>>>> that
> > > > > > >>>>>>>> developers could easily assess and discuss style
> settings
> > > and keep
> > > > > > >>>>> track
> > > > > > >>>>>>> of
> > > > > > >>>>>>>> changes in these. (note how Kafka folks 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 community members.
> > > Moreover, this
> > > > > > >>>>>>>>> suite is no longer checks rules we previously
> 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 consider the Apache Kafka
> > > code
> > > > > > style
> > > > > > >>> [5]
> > > > > > >>>>>>>>> way and configure for the Ignite project a
> > > > > > maven-checkstyle-plugin
> > > > > > >>>>>>>>> with its own maven profile and run it simultaneously
> with
> > > other
> > > > > > TC.
> > > > > > >>> We
> > > > > > >>>>>>>>> can also enable the previously configured inspection
> > > rules, so no
> > > > > > >>>>>>>>> coding style violations will be missed.
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> I see some advantages of using a maven plugin:
> > > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > > > > >>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > > >>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > >>>>>>>>> [3]
> > > > > > >>>>>>>
> > > > > > >>>>>
> > > > > > >>>
> > > > > >
> > >
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > > >>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > > >>>>>>>>> [5]
> https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> mr.weider@
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> &gt; wrote:
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity
> > > > > > >>>>>>>>>> Bug is filed [1]
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> mr.weider@
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> &gt; wrote:
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> Investigating problem, stand by.
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> dpavlov@
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> &gt; 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 next 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
>

Re: Code inspection

[Павлухин Иван <vo...@gmail.com>]

Nikolay,

> Should the community spend TC resources for  prototype?
Why not? I think it is not bad idea to run all tests against 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 with other
Igniters. I think it is the cheapest way to check the idea because the
check is fully automated. Requiring a human feedback is much 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 skipping tests
execution if inspections detect a problem?

чт, 14 февр. 2019 г. в 14:14, Nikolay Izhikov <ni...@apache.org>:
>
> 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 prototype.
>
> 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?
>
>
> ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <vo...@gmail.com>:
>
> > 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 outline 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 that message).
> >
> > We have a document defining code style which every contributor should
> > follow [1]. And many points can be checked automatically. Personally,
> > I do not see much need in writing good javadocs for prototype. Why
> > should I stub it to be able run any build on TC?
> >
> > Also, we a have a review process which should be applied to every
> > patch. Partially it is described in [2]. And due to this process every
> > patch should not introduce new failures on TC. So, the patch should
> > not be merged if inspections failed.
> >
> > P.S. Something more about prototypes and production code. There is a
> > common bad practice in software engineering. It is turning prototypes
> > into production code. Often it is much faster to create a prototype by
> > price of violating some rules of writing "clean code". And often
> > prototype after successful piloting is turned into production code.
> > And it is very easy in practice to keep some pieces of 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" from the beginning.
> > So, only ideas are taken from the prototype and a code is fully
> > rewritten.
> >
> > [1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > [2] https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> >
> > ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <ma...@gmail.com>:
> > >
> > > Ivan,
> > >
> > > As the first implementation of this addition, I'd prefer to make it
> > > working like _Licenses Headers_ suite check. It will fail when some of
> > > the code style checks violated. Moreover, these licenses header checks
> > > can be included in the checkstyle plugin configuration.
> > >
> > > In general, I'd prefer to have a compilation fail error with code
> > > style checks and after we will get a stable checkstyle suite I propose
> > > to change it in a "compilation error" way. If we are talking about the
> > > coding style convenient for most of the community members I see no
> > > difference with coding sketches or production-ready branches equally.
> > > Indeed, no one will be against unused imports [or spaces 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() == 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 <ni...@apache.org>
> > wrote:
> > > >
> > > > Actually, I dont see anything wrong with failing *compilation* task.
> > > >
> > > > I think one should use project code style for everyday 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?
> > > >
> > > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.weider@gmail.com:
> > > >
> > > > > I guess that was about failing build configuration with Checkstype,
> > not
> > > > > compilation build itself.
> > > > >
> > > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <vo...@gmail.com>
> > wrote:
> > > > > >
> > > > > > Folks,
> > > > > >
> > > > > > Are you going to fail job compiling Ignite sources [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 convenient to skip some style
> > > > > > requirements for such sketches (e.g. well formed javadocs).
> > > > > >
> > > > > > [1]
> > > > >
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > > >
> > > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <nizhikov@apache.org
> > >:
> > > > > >>
> > > > > >> Petr, we should have 1 configuration for project, may be 1
> > configuration
> > > > > >> per programming language.
> > > > > >>
> > > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
> > > > > >>
> > > > > >>> I was asking about how many build configuration is intended? One
> > for
> > > > > all
> > > > > >>> and multiple per module?
> > > > > >>>
> > > > > >>> With IDEA inspections it was going to be build configuration per
> > > > > module.
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>> On 11 Feb 2019, at 11:24, Nikolay Izhikov <ni...@apache.org>
> > > > > wrote:
> > > > > >>>>
> > > > > >>>> Hello, Petr.
> > > > > >>>>
> > > > > >>>> Are you saying that we have not single build task? And each
> > module
> > > > > builds
> > > > > >>>> when it required? If yes, then I propose to create a task like
> > > > > "Licence
> > > > > >>>> check" which will be run for every patch.
> > > > > >>>>
> > > > > >>>> My point is that violation of codestyle should be treated as
> > hard as
> > > > > >>>> compile error.
> > > > > >>>>
> > > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com:
> > > > > >>>>
> > > > > >>>>> Is build configuration Inspections [Core] meant to transform
> > into
> > > > > single
> > > > > >>>>> all-modules check build configuration (without module
> > subdivision)?
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <
> > 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/1065-checkstyle-idea
> > > > > >>>>>>
> > > > > >>>>>> I propose do the following:
> > > > > >>>>>>
> > > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > > > >>>>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite" suite.
> > Ignite
> > > > > has
> > > > > >>>>> to
> > > > > >>>>>> fail to build if patch violates codestyle.
> > > > > >>>>>>
> > > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <
> > vololo100@gmail.com>:
> > > > > >>>>>>
> > > > > >>>>>>> Hi,
> > > > > >>>>>>>
> > > > > >>>>>>> I also think that some warning from IDEA that some code
> > style rule
> > > > > is
> > > > > >>>>>>> violated is a must-have.
> > > > > >>>>>>>
> > > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <
> > oignatenko@gridgain.com
> > > > > >:
> > > > > >>>>>>>>
> > > > > >>>>>>>> Hi Maxim,
> > > > > >>>>>>>>
> > > > > >>>>>>>> I believe that whatever style checks we establish at
> > Teamcity, we
> > > > > >>>>> better
> > > > > >>>>>>>> take care of making it easy for developers to find and fix
> > > > > violations
> > > > > >>>>> in
> > > > > >>>>>>>> their typical dev environment (for Ignite this means, in
> > IDEA). I
> > > > > >>> think
> > > > > >>>>>>> it
> > > > > >>>>>>>> is important that developers can maintain 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 just 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 checkstyle - I recommend
> > keeping
> > > > > >>> its
> > > > > >>>>>>>> config file somewhere in the project under version control.
> > I
> > > > > used to
> > > > > >>>>>>>> maintain such a shared style config at one of past jobs and
> > after
> > > > > >>> some
> > > > > >>>>>>>> experimenting it turned out most convenient to have it this
> > way -
> > > > > so
> > > > > >>>>> that
> > > > > >>>>>>>> developers could easily assess and discuss style settings
> > and keep
> > > > > >>>>> track
> > > > > >>>>>>> of
> > > > > >>>>>>>> changes in these. (note how Kafka folks 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 community members.
> > Moreover, this
> > > > > >>>>>>>>> suite is no longer checks rules we previously 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 consider the Apache Kafka
> > code
> > > > > style
> > > > > >>> [5]
> > > > > >>>>>>>>> way and configure for the Ignite project a
> > > > > maven-checkstyle-plugin
> > > > > >>>>>>>>> with its own maven profile and run it simultaneously with
> > other
> > > > > TC.
> > > > > >>> We
> > > > > >>>>>>>>> can also enable the previously configured inspection
> > rules, so no
> > > > > >>>>>>>>> coding style violations will be missed.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> I see some advantages of using a maven plugin:
> > > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > > > >>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > > >>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> > > > > >>>>>>>>> [3]
> > > > > >>>>>>>
> > > > > >>>>>
> > > > > >>>
> > > > >
> > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > > >>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> > > > > >>>>>>>>> [5] https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> > > > > >>>>>>>>
> > > > > >>>>>>>>> mr.weider@
> > > > > >>>>>>>>
> > > > > >>>>>>>>> &gt; wrote:
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity
> > > > > >>>>>>>>>> Bug is filed [1]
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> > > > > >>>>>>>>
> > > > > >>>>>>>>> mr.weider@
> > > > > >>>>>>>>
> > > > > >>>>>>>>> &gt; wrote:
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Investigating problem, stand by.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> > > > > >>>>>>>>
> > > > > >>>>>>>>> dpavlov@
> > > > > >>>>>>>>
> > > > > >>>>>>>>> &gt; 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 next 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

Re: Code inspection

[Nikolay Izhikov <ni...@apache.org>]

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 prototype.

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?


ср, 13 февр. 2019 г. в 16:45, Павлухин Иван <vo...@gmail.com>:

> 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 outline 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 that message).
>
> We have a document defining code style which every contributor should
> follow [1]. And many points can be checked automatically. Personally,
> I do not see much need in writing good javadocs for prototype. Why
> should I stub it to be able run any build on TC?
>
> Also, we a have a review process which should be applied to every
> patch. Partially it is described in [2]. And due to this process every
> patch should not introduce new failures on TC. So, the patch should
> not be merged if inspections failed.
>
> P.S. Something more about prototypes and production code. There is a
> common bad practice in software engineering. It is turning prototypes
> into production code. Often it is much faster to create a prototype by
> price of violating some rules of writing "clean code". And often
> prototype after successful piloting is turned into production code.
> And it is very easy in practice to keep some pieces of 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" from the beginning.
> So, only ideas are taken from the prototype and a code is fully
> rewritten.
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> [2] https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
>
> ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <ma...@gmail.com>:
> >
> > Ivan,
> >
> > As the first implementation of this addition, I'd prefer to make it
> > working like _Licenses Headers_ suite check. It will fail when some of
> > the code style checks violated. Moreover, these licenses header checks
> > can be included in the checkstyle plugin configuration.
> >
> > In general, I'd prefer to have a compilation fail error with code
> > style checks and after we will get a stable checkstyle suite I propose
> > to change it in a "compilation error" way. If we are talking about the
> > coding style convenient for most of the community members I see no
> > difference with coding sketches or production-ready branches equally.
> > Indeed, no one will be against unused imports [or spaces 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() == 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 <ni...@apache.org>
> wrote:
> > >
> > > Actually, I dont see anything wrong with failing *compilation* task.
> > >
> > > I think one should use project code style for everyday 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?
> > >
> > > ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.weider@gmail.com:
> > >
> > > > I guess that was about failing build configuration with Checkstype,
> not
> > > > compilation build itself.
> > > >
> > > > > On 12 Feb 2019, at 18:03, Павлухин Иван <vo...@gmail.com>
> wrote:
> > > > >
> > > > > Folks,
> > > > >
> > > > > Are you going to fail job compiling Ignite sources [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 convenient to skip some style
> > > > > requirements for such sketches (e.g. well formed javadocs).
> > > > >
> > > > > [1]
> > > >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > > >
> > > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <nizhikov@apache.org
> >:
> > > > >>
> > > > >> Petr, we should have 1 configuration for project, may be 1
> configuration
> > > > >> per programming language.
> > > > >>
> > > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
> > > > >>
> > > > >>> I was asking about how many build configuration is intended? One
> for
> > > > all
> > > > >>> and multiple per module?
> > > > >>>
> > > > >>> With IDEA inspections it was going to be build configuration per
> > > > module.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>> On 11 Feb 2019, at 11:24, Nikolay Izhikov <ni...@apache.org>
> > > > wrote:
> > > > >>>>
> > > > >>>> Hello, Petr.
> > > > >>>>
> > > > >>>> Are you saying that we have not single build task? And each
> module
> > > > builds
> > > > >>>> when it required? If yes, then I propose to create a task like
> > > > "Licence
> > > > >>>> check" which will be run for every patch.
> > > > >>>>
> > > > >>>> My point is that violation of codestyle should be treated as
> hard as
> > > > >>>> compile error.
> > > > >>>>
> > > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com:
> > > > >>>>
> > > > >>>>> Is build configuration Inspections [Core] meant to transform
> into
> > > > single
> > > > >>>>> all-modules check build configuration (without module
> subdivision)?
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <
> 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/1065-checkstyle-idea
> > > > >>>>>>
> > > > >>>>>> I propose do the following:
> > > > >>>>>>
> > > > >>>>>> 1. Migrate current checks to checkstyle.
> > > > >>>>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite" suite.
> Ignite
> > > > has
> > > > >>>>> to
> > > > >>>>>> fail to build if patch violates codestyle.
> > > > >>>>>>
> > > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <
> vololo100@gmail.com>:
> > > > >>>>>>
> > > > >>>>>>> Hi,
> > > > >>>>>>>
> > > > >>>>>>> I also think that some warning from IDEA that some code
> style rule
> > > > is
> > > > >>>>>>> violated is a must-have.
> > > > >>>>>>>
> > > > >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <
> oignatenko@gridgain.com
> > > > >:
> > > > >>>>>>>>
> > > > >>>>>>>> Hi Maxim,
> > > > >>>>>>>>
> > > > >>>>>>>> I believe that whatever style checks we establish at
> Teamcity, we
> > > > >>>>> better
> > > > >>>>>>>> take care of making it easy for developers to find and fix
> > > > violations
> > > > >>>>> in
> > > > >>>>>>>> their typical dev environment (for Ignite this means, in
> IDEA). I
> > > > >>> think
> > > > >>>>>>> it
> > > > >>>>>>>> is important that developers can maintain 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 just 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 checkstyle - I recommend
> keeping
> > > > >>> its
> > > > >>>>>>>> config file somewhere in the project under version control.
> I
> > > > used to
> > > > >>>>>>>> maintain such a shared style config at one of past jobs and
> after
> > > > >>> some
> > > > >>>>>>>> experimenting it turned out most convenient to have it this
> way -
> > > > so
> > > > >>>>> that
> > > > >>>>>>>> developers could easily assess and discuss style settings
> and keep
> > > > >>>>> track
> > > > >>>>>>> of
> > > > >>>>>>>> changes in these. (note how Kafka folks 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 community members.
> Moreover, this
> > > > >>>>>>>>> suite is no longer checks rules we previously 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 consider the Apache Kafka
> code
> > > > style
> > > > >>> [5]
> > > > >>>>>>>>> way and configure for the Ignite project a
> > > > maven-checkstyle-plugin
> > > > >>>>>>>>> with its own maven profile and run it simultaneously with
> other
> > > > TC.
> > > > >>> We
> > > > >>>>>>>>> can also enable the previously configured inspection
> rules, so no
> > > > >>>>>>>>> coding style violations will be missed.
> > > > >>>>>>>>>
> > > > >>>>>>>>> I see some advantages of using a maven plugin:
> > > > >>>>>>>>> - an IDE agnostic way for code checks
> > > > >>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > > >>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> > > > >>>>>>>>> [3]
> > > > >>>>>>>
> > > > >>>>>
> > > > >>>
> > > >
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > > >>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> > > > >>>>>>>>> [5] https://github.com/apache/kafka/tree/trunk/checkstyle
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> > > > >>>>>>>>
> > > > >>>>>>>>> mr.weider@
> > > > >>>>>>>>
> > > > >>>>>>>>> &gt; wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity
> > > > >>>>>>>>>> Bug is filed [1]
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> > > > >>>>>>>>
> > > > >>>>>>>>> mr.weider@
> > > > >>>>>>>>
> > > > >>>>>>>>> &gt; wrote:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Investigating problem, stand by.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> > > > >>>>>>>>
> > > > >>>>>>>>> dpavlov@
> > > > >>>>>>>>
> > > > >>>>>>>>> &gt; 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 next 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
>

Re: Code inspection

[Павлухин Иван <vo...@gmail.com>]

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 outline 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 that message).

We have a document defining code style which every contributor should
follow [1]. And many points can be checked automatically. Personally,
I do not see much need in writing good javadocs for prototype. Why
should I stub it to be able run any build on TC?

Also, we a have a review process which should be applied to every
patch. Partially it is described in [2]. And due to this process every
patch should not introduce new failures on TC. So, the patch should
not be merged if inspections failed.

P.S. Something more about prototypes and production code. There is a
common bad practice in software engineering. It is turning prototypes
into production code. Often it is much faster to create a prototype by
price of violating some rules of writing "clean code". And often
prototype after successful piloting is turned into production code.
And it is very easy in practice to keep some pieces of 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" from the beginning.
So, only ideas are taken from the prototype and a code is fully
rewritten.

[1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
[2] https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist

ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov <ma...@gmail.com>:
>
> Ivan,
>
> As the first implementation of this addition, I'd prefer to make it
> working like _Licenses Headers_ suite check. It will fail when some of
> the code style checks violated. Moreover, these licenses header checks
> can be included in the checkstyle plugin configuration.
>
> In general, I'd prefer to have a compilation fail error with code
> style checks and after we will get a stable checkstyle suite I propose
> to change it in a "compilation error" way. If we are talking about the
> coding style convenient for most of the community members I see no
> difference with coding sketches or production-ready branches equally.
> Indeed, no one will be against unused imports [or spaces 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() == 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 <ni...@apache.org> wrote:
> >
> > Actually, I dont see anything wrong with failing *compilation* task.
> >
> > I think one should use project code style for everyday 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?
> >
> > ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.weider@gmail.com:
> >
> > > I guess that was about failing build configuration with Checkstype, not
> > > compilation build itself.
> > >
> > > > On 12 Feb 2019, at 18:03, Павлухин Иван <vo...@gmail.com> wrote:
> > > >
> > > > Folks,
> > > >
> > > > Are you going to fail job compiling Ignite sources [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 convenient to skip some style
> > > > requirements for such sketches (e.g. well formed javadocs).
> > > >
> > > > [1]
> > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > >
> > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <ni...@apache.org>:
> > > >>
> > > >> Petr, we should have 1 configuration for project, may be 1 configuration
> > > >> per programming language.
> > > >>
> > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
> > > >>
> > > >>> I was asking about how many build configuration is intended? One for
> > > all
> > > >>> and multiple per module?
> > > >>>
> > > >>> With IDEA inspections it was going to be build configuration per
> > > module.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>> On 11 Feb 2019, at 11:24, Nikolay Izhikov <ni...@apache.org>
> > > wrote:
> > > >>>>
> > > >>>> Hello, Petr.
> > > >>>>
> > > >>>> Are you saying that we have not single build task? And each module
> > > builds
> > > >>>> when it required? If yes, then I propose to create a task like
> > > "Licence
> > > >>>> check" which will be run for every patch.
> > > >>>>
> > > >>>> My point is that violation of codestyle should be treated as hard as
> > > >>>> compile error.
> > > >>>>
> > > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com:
> > > >>>>
> > > >>>>> Is build configuration Inspections [Core] meant to transform into
> > > single
> > > >>>>> all-modules check build configuration (without module subdivision)?
> > > >>>>>
> > > >>>>>
> > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <ni...@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/1065-checkstyle-idea
> > > >>>>>>
> > > >>>>>> I propose do the following:
> > > >>>>>>
> > > >>>>>> 1. Migrate current checks to checkstyle.
> > > >>>>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite" suite. Ignite
> > > has
> > > >>>>> to
> > > >>>>>> fail to build if patch violates codestyle.
> > > >>>>>>
> > > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <vo...@gmail.com>:
> > > >>>>>>
> > > >>>>>>> Hi,
> > > >>>>>>>
> > > >>>>>>> I also think that some warning from IDEA that some code style rule
> > > is
> > > >>>>>>> violated is a must-have.
> > > >>>>>>>
> > > >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <oignatenko@gridgain.com
> > > >:
> > > >>>>>>>>
> > > >>>>>>>> Hi Maxim,
> > > >>>>>>>>
> > > >>>>>>>> I believe that whatever style checks we establish at Teamcity, we
> > > >>>>> better
> > > >>>>>>>> take care of making it easy for developers to find and fix
> > > violations
> > > >>>>> in
> > > >>>>>>>> their typical dev environment (for Ignite this means, in IDEA). I
> > > >>> think
> > > >>>>>>> it
> > > >>>>>>>> is important that developers can maintain 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 just 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 checkstyle - I recommend keeping
> > > >>> its
> > > >>>>>>>> config file somewhere in the project under version control. I
> > > used to
> > > >>>>>>>> maintain such a shared style config at one of past jobs and after
> > > >>> some
> > > >>>>>>>> experimenting it turned out most convenient to have it this way -
> > > so
> > > >>>>> that
> > > >>>>>>>> developers could easily assess and discuss style settings and keep
> > > >>>>> track
> > > >>>>>>> of
> > > >>>>>>>> changes in these. (note how Kafka folks 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 community members. Moreover, this
> > > >>>>>>>>> suite is no longer checks rules we previously 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 consider the Apache Kafka code
> > > style
> > > >>> [5]
> > > >>>>>>>>> way and configure for the Ignite project a
> > > maven-checkstyle-plugin
> > > >>>>>>>>> with its own maven profile and run it simultaneously with other
> > > TC.
> > > >>> We
> > > >>>>>>>>> can also enable the previously configured inspection rules, so no
> > > >>>>>>>>> coding style violations will be missed.
> > > >>>>>>>>>
> > > >>>>>>>>> I see some advantages of using a maven plugin:
> > > >>>>>>>>> - an IDE agnostic way for code checks
> > > >>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > >>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> > > >>>>>>>>> [3]
> > > >>>>>>>
> > > >>>>>
> > > >>>
> > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > >>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> > > >>>>>>>>> [5] https://github.com/apache/kafka/tree/trunk/checkstyle
> > > >>>>>>>>>
> > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> > > >>>>>>>>
> > > >>>>>>>>> mr.weider@
> > > >>>>>>>>
> > > >>>>>>>>> &gt; wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity
> > > >>>>>>>>>> Bug is filed [1]
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> > > >>>>>>>>
> > > >>>>>>>>> mr.weider@
> > > >>>>>>>>
> > > >>>>>>>>> &gt; wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Investigating problem, stand by.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> > > >>>>>>>>
> > > >>>>>>>>> dpavlov@
> > > >>>>>>>>
> > > >>>>>>>>> &gt; 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 next 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

Re: Code inspection

[Maxim Muzafarov <ma...@gmail.com>]

Ivan,

As the first implementation of this addition, I'd prefer to make it
working like _Licenses Headers_ suite check. It will fail when some of
the code style checks violated. Moreover, these licenses header checks
can be included in the checkstyle plugin configuration.

In general, I'd prefer to have a compilation fail error with code
style checks and after we will get a stable checkstyle suite I propose
to change it in a "compilation error" way. If we are talking about the
coding style convenient for most of the community members I see no
difference with coding sketches or production-ready branches equally.
Indeed, no one will be against unused imports [or spaces 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() == 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 <ni...@apache.org> wrote:
>
> Actually, I dont see anything wrong with failing *compilation* task.
>
> I think one should use project code style for everyday 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?
>
> ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.weider@gmail.com:
>
> > I guess that was about failing build configuration with Checkstype, not
> > compilation build itself.
> >
> > > On 12 Feb 2019, at 18:03, Павлухин Иван <vo...@gmail.com> wrote:
> > >
> > > Folks,
> > >
> > > Are you going to fail job compiling Ignite sources [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 convenient to skip some style
> > > requirements for such sketches (e.g. well formed javadocs).
> > >
> > > [1]
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > >
> > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <ni...@apache.org>:
> > >>
> > >> Petr, we should have 1 configuration for project, may be 1 configuration
> > >> per programming language.
> > >>
> > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
> > >>
> > >>> I was asking about how many build configuration is intended? One for
> > all
> > >>> and multiple per module?
> > >>>
> > >>> With IDEA inspections it was going to be build configuration per
> > module.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> On 11 Feb 2019, at 11:24, Nikolay Izhikov <ni...@apache.org>
> > wrote:
> > >>>>
> > >>>> Hello, Petr.
> > >>>>
> > >>>> Are you saying that we have not single build task? And each module
> > builds
> > >>>> when it required? If yes, then I propose to create a task like
> > "Licence
> > >>>> check" which will be run for every patch.
> > >>>>
> > >>>> My point is that violation of codestyle should be treated as hard as
> > >>>> compile error.
> > >>>>
> > >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com:
> > >>>>
> > >>>>> Is build configuration Inspections [Core] meant to transform into
> > single
> > >>>>> all-modules check build configuration (without module subdivision)?
> > >>>>>
> > >>>>>
> > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <ni...@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/1065-checkstyle-idea
> > >>>>>>
> > >>>>>> I propose do the following:
> > >>>>>>
> > >>>>>> 1. Migrate current checks to checkstyle.
> > >>>>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite" suite. Ignite
> > has
> > >>>>> to
> > >>>>>> fail to build if patch violates codestyle.
> > >>>>>>
> > >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <vo...@gmail.com>:
> > >>>>>>
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>> I also think that some warning from IDEA that some code style rule
> > is
> > >>>>>>> violated is a must-have.
> > >>>>>>>
> > >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <oignatenko@gridgain.com
> > >:
> > >>>>>>>>
> > >>>>>>>> Hi Maxim,
> > >>>>>>>>
> > >>>>>>>> I believe that whatever style checks we establish at Teamcity, we
> > >>>>> better
> > >>>>>>>> take care of making it easy for developers to find and fix
> > violations
> > >>>>> in
> > >>>>>>>> their typical dev environment (for Ignite this means, in IDEA). I
> > >>> think
> > >>>>>>> it
> > >>>>>>>> is important that developers can maintain 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 just 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 checkstyle - I recommend keeping
> > >>> its
> > >>>>>>>> config file somewhere in the project under version control. I
> > used to
> > >>>>>>>> maintain such a shared style config at one of past jobs and after
> > >>> some
> > >>>>>>>> experimenting it turned out most convenient to have it this way -
> > so
> > >>>>> that
> > >>>>>>>> developers could easily assess and discuss style settings and keep
> > >>>>> track
> > >>>>>>> of
> > >>>>>>>> changes in these. (note how Kafka folks 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 community members. Moreover, this
> > >>>>>>>>> suite is no longer checks rules we previously 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 consider the Apache Kafka code
> > style
> > >>> [5]
> > >>>>>>>>> way and configure for the Ignite project a
> > maven-checkstyle-plugin
> > >>>>>>>>> with its own maven profile and run it simultaneously with other
> > TC.
> > >>> We
> > >>>>>>>>> can also enable the previously configured inspection rules, so no
> > >>>>>>>>> coding style violations will be missed.
> > >>>>>>>>>
> > >>>>>>>>> I see some advantages of using a maven plugin:
> > >>>>>>>>> - an IDE agnostic way for code checks
> > >>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > >>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> > >>>>>>>>> [3]
> > >>>>>>>
> > >>>>>
> > >>>
> > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > >>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> > >>>>>>>>> [5] https://github.com/apache/kafka/tree/trunk/checkstyle
> > >>>>>>>>>
> > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> > >>>>>>>>
> > >>>>>>>>> mr.weider@
> > >>>>>>>>
> > >>>>>>>>> &gt; wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity
> > >>>>>>>>>> Bug is filed [1]
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> > >>>>>>>>>>
> > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> > >>>>>>>>
> > >>>>>>>>> mr.weider@
> > >>>>>>>>
> > >>>>>>>>> &gt; wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> Investigating problem, stand by.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> > >>>>>>>>
> > >>>>>>>>> dpavlov@
> > >>>>>>>>
> > >>>>>>>>> &gt; 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 next 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
> >
> >

Re: Code inspection

[Nikolay Izhikov <ni...@apache.org>]

Actually, I dont see anything wrong with failing *compilation* task.

I think one should use project code style for everyday 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?

ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.weider@gmail.com:

> I guess that was about failing build configuration with Checkstype, not
> compilation build itself.
>
> > On 12 Feb 2019, at 18:03, Павлухин Иван <vo...@gmail.com> wrote:
> >
> > Folks,
> >
> > Are you going to fail job compiling Ignite sources [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 convenient to skip some style
> > requirements for such sketches (e.g. well formed javadocs).
> >
> > [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> >
> > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <ni...@apache.org>:
> >>
> >> Petr, we should have 1 configuration for project, may be 1 configuration
> >> per programming language.
> >>
> >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
> >>
> >>> I was asking about how many build configuration is intended? One for
> all
> >>> and multiple per module?
> >>>
> >>> With IDEA inspections it was going to be build configuration per
> module.
> >>>
> >>>
> >>>
> >>>
> >>>> On 11 Feb 2019, at 11:24, Nikolay Izhikov <ni...@apache.org>
> wrote:
> >>>>
> >>>> Hello, Petr.
> >>>>
> >>>> Are you saying that we have not single build task? And each module
> builds
> >>>> when it required? If yes, then I propose to create a task like
> "Licence
> >>>> check" which will be run for every patch.
> >>>>
> >>>> My point is that violation of codestyle should be treated as hard as
> >>>> compile error.
> >>>>
> >>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com:
> >>>>
> >>>>> Is build configuration Inspections [Core] meant to transform into
> single
> >>>>> all-modules check build configuration (without module subdivision)?
> >>>>>
> >>>>>
> >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <ni...@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/1065-checkstyle-idea
> >>>>>>
> >>>>>> I propose do the following:
> >>>>>>
> >>>>>> 1. Migrate current checks to checkstyle.
> >>>>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite" suite. Ignite
> has
> >>>>> to
> >>>>>> fail to build if patch violates codestyle.
> >>>>>>
> >>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <vo...@gmail.com>:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I also think that some warning from IDEA that some code style rule
> is
> >>>>>>> violated is a must-have.
> >>>>>>>
> >>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <oignatenko@gridgain.com
> >:
> >>>>>>>>
> >>>>>>>> Hi Maxim,
> >>>>>>>>
> >>>>>>>> I believe that whatever style checks we establish at Teamcity, we
> >>>>> better
> >>>>>>>> take care of making it easy for developers to find and fix
> violations
> >>>>> in
> >>>>>>>> their typical dev environment (for Ignite this means, in IDEA). I
> >>> think
> >>>>>>> it
> >>>>>>>> is important that developers can maintain 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 just 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 checkstyle - I recommend keeping
> >>> its
> >>>>>>>> config file somewhere in the project under version control. I
> used to
> >>>>>>>> maintain such a shared style config at one of past jobs and after
> >>> some
> >>>>>>>> experimenting it turned out most convenient to have it this way -
> so
> >>>>> that
> >>>>>>>> developers could easily assess and discuss style settings and keep
> >>>>> track
> >>>>>>> of
> >>>>>>>> changes in these. (note how Kafka folks 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 community members. Moreover, this
> >>>>>>>>> suite is no longer checks rules we previously 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 consider the Apache Kafka code
> style
> >>> [5]
> >>>>>>>>> way and configure for the Ignite project a
> maven-checkstyle-plugin
> >>>>>>>>> with its own maven profile and run it simultaneously with other
> TC.
> >>> We
> >>>>>>>>> can also enable the previously configured inspection rules, so no
> >>>>>>>>> coding style violations will be missed.
> >>>>>>>>>
> >>>>>>>>> I see some advantages of using a maven plugin:
> >>>>>>>>> - an IDE agnostic way for code checks
> >>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> >>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> >>>>>>>>> [3]
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> >>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> >>>>>>>>> [5] https://github.com/apache/kafka/tree/trunk/checkstyle
> >>>>>>>>>
> >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> >>>>>>>>
> >>>>>>>>> mr.weider@
> >>>>>>>>
> >>>>>>>>> &gt; wrote:
> >>>>>>>>>>
> >>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity
> >>>>>>>>>> Bug is filed [1]
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> >>>>>>>>>>
> >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> >>>>>>>>
> >>>>>>>>> mr.weider@
> >>>>>>>>
> >>>>>>>>> &gt; wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Investigating problem, stand by.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> >>>>>>>>
> >>>>>>>>> dpavlov@
> >>>>>>>>
> >>>>>>>>> &gt; 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 next 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
>
>

Re: Code inspection

[Petr Ivanov <mr...@gmail.com>]

I guess that was about failing build configuration with Checkstype, not compilation build itself.

> On 12 Feb 2019, at 18:03, Павлухин Иван <vo...@gmail.com> wrote:
> 
> Folks,
> 
> Are you going to fail job compiling Ignite sources [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 convenient to skip some style
> requirements for such sketches (e.g. well formed javadocs).
> 
> [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> 
> пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <ni...@apache.org>:
>> 
>> Petr, we should have 1 configuration for project, may be 1 configuration
>> per programming language.
>> 
>> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
>> 
>>> I was asking about how many build configuration is intended? One for all
>>> and multiple per module?
>>> 
>>> With IDEA inspections it was going to be build configuration per module.
>>> 
>>> 
>>> 
>>> 
>>>> On 11 Feb 2019, at 11:24, Nikolay Izhikov <ni...@apache.org> wrote:
>>>> 
>>>> Hello, Petr.
>>>> 
>>>> Are you saying that we have not single build task? And each module builds
>>>> when it required? If yes, then I propose to create a task like "Licence
>>>> check" which will be run for every patch.
>>>> 
>>>> My point is that violation of codestyle should be treated as hard as
>>>> compile error.
>>>> 
>>>> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com:
>>>> 
>>>>> Is build configuration Inspections [Core] meant to transform into single
>>>>> all-modules check build configuration (without module subdivision)?
>>>>> 
>>>>> 
>>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <ni...@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/1065-checkstyle-idea
>>>>>> 
>>>>>> I propose do the following:
>>>>>> 
>>>>>> 1. Migrate current checks to checkstyle.
>>>>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite" suite. Ignite has
>>>>> to
>>>>>> fail to build if patch violates codestyle.
>>>>>> 
>>>>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <vo...@gmail.com>:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I also think that some warning from IDEA that some code style rule is
>>>>>>> violated is a must-have.
>>>>>>> 
>>>>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <oi...@gridgain.com>:
>>>>>>>> 
>>>>>>>> Hi Maxim,
>>>>>>>> 
>>>>>>>> I believe that whatever style checks we establish at Teamcity, we
>>>>> better
>>>>>>>> take care of making it easy for developers to find and fix violations
>>>>> in
>>>>>>>> their typical dev environment (for Ignite this means, in IDEA). I
>>> think
>>>>>>> it
>>>>>>>> is important that developers can maintain 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 just 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 checkstyle - I recommend keeping
>>> its
>>>>>>>> config file somewhere in the project under version control. I used to
>>>>>>>> maintain such a shared style config at one of past jobs and after
>>> some
>>>>>>>> experimenting it turned out most convenient to have it this way - so
>>>>> that
>>>>>>>> developers could easily assess and discuss style settings and keep
>>>>> track
>>>>>>> of
>>>>>>>> changes in these. (note how Kafka folks 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 community members. Moreover, this
>>>>>>>>> suite is no longer checks rules we previously 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 consider the Apache Kafka code style
>>> [5]
>>>>>>>>> way and configure for the Ignite project a maven-checkstyle-plugin
>>>>>>>>> with its own maven profile and run it simultaneously with other TC.
>>> We
>>>>>>>>> can also enable the previously configured inspection rules, so no
>>>>>>>>> coding style violations will be missed.
>>>>>>>>> 
>>>>>>>>> I see some advantages of using a maven plugin:
>>>>>>>>> - an IDE agnostic way for code checks
>>>>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
>>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
>>>>>>>>> [3]
>>>>>>> 
>>>>> 
>>> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
>>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
>>>>>>>>> [5] https://github.com/apache/kafka/tree/trunk/checkstyle
>>>>>>>>> 
>>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
>>>>>>>> 
>>>>>>>>> mr.weider@
>>>>>>>> 
>>>>>>>>> &gt; wrote:
>>>>>>>>>> 
>>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity
>>>>>>>>>> Bug is filed [1]
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
>>>>>>>>>> 
>>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
>>>>>>>> 
>>>>>>>>> mr.weider@
>>>>>>>> 
>>>>>>>>> &gt; wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Investigating problem, stand by.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
>>>>>>>> 
>>>>>>>>> dpavlov@
>>>>>>>> 
>>>>>>>>> &gt; 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 next 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

Re: Code inspection

[Павлухин Иван <vo...@gmail.com>]

Folks,

Are you going to fail job compiling Ignite sources [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 convenient to skip some style
requirements for such sketches (e.g. well formed javadocs).

[1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite

пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov <ni...@apache.org>:
>
> Petr, we should have 1 configuration for project, may be 1 configuration
> per programming language.
>
> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:
>
> > I was asking about how many build configuration is intended? One for all
> > and multiple per module?
> >
> > With IDEA inspections it was going to be build configuration per module.
> >
> >
> >
> >
> > > On 11 Feb 2019, at 11:24, Nikolay Izhikov <ni...@apache.org> wrote:
> > >
> > > Hello, Petr.
> > >
> > > Are you saying that we have not single build task? And each module builds
> > > when it required? If yes, then I propose to create a task like "Licence
> > > check" which will be run for every patch.
> > >
> > > My point is that violation of codestyle should be treated as hard as
> > > compile error.
> > >
> > > пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com:
> > >
> > >> Is build configuration Inspections [Core] meant to transform into single
> > >> all-modules check build configuration (without module subdivision)?
> > >>
> > >>
> > >>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <ni...@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/1065-checkstyle-idea
> > >>>
> > >>> I propose do the following:
> > >>>
> > >>> 1. Migrate current checks to checkstyle.
> > >>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite" suite. Ignite has
> > >> to
> > >>> fail to build if patch violates codestyle.
> > >>>
> > >>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <vo...@gmail.com>:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>> I also think that some warning from IDEA that some code style rule is
> > >>>> violated is a must-have.
> > >>>>
> > >>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <oi...@gridgain.com>:
> > >>>>>
> > >>>>> Hi Maxim,
> > >>>>>
> > >>>>> I believe that whatever style checks we establish at Teamcity, we
> > >> better
> > >>>>> take care of making it easy for developers to find and fix violations
> > >> in
> > >>>>> their typical dev environment (for Ignite this means, in IDEA). I
> > think
> > >>>> it
> > >>>>> is important that developers can maintain 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 just 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 checkstyle - I recommend keeping
> > its
> > >>>>> config file somewhere in the project under version control. I used to
> > >>>>> maintain such a shared style config at one of past jobs and after
> > some
> > >>>>> experimenting it turned out most convenient to have it this way - so
> > >> that
> > >>>>> developers could easily assess and discuss style settings and keep
> > >> track
> > >>>> of
> > >>>>> changes in these. (note how Kafka folks 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 community members. Moreover, this
> > >>>>>> suite is no longer checks rules we previously 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 consider the Apache Kafka code style
> > [5]
> > >>>>>> way and configure for the Ignite project a maven-checkstyle-plugin
> > >>>>>> with its own maven profile and run it simultaneously with other TC.
> > We
> > >>>>>> can also enable the previously configured inspection rules, so no
> > >>>>>> coding style violations will be missed.
> > >>>>>>
> > >>>>>> I see some advantages of using a maven plugin:
> > >>>>>> - an IDE agnostic way for code checks
> > >>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > >>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> > >>>>>> [3]
> > >>>>
> > >>
> > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > >>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> > >>>>>> [5] https://github.com/apache/kafka/tree/trunk/checkstyle
> > >>>>>>
> > >>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> > >>>>>
> > >>>>>> mr.weider@
> > >>>>>
> > >>>>>> &gt; wrote:
> > >>>>>>>
> > >>>>>>> It seems there is bug in latest 2018.2 TeamCity
> > >>>>>>> Bug is filed [1]
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> > >>>>>>>
> > >>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> > >>>>>
> > >>>>>> mr.weider@
> > >>>>>
> > >>>>>> &gt; wrote:
> > >>>>>>>>
> > >>>>>>>> Investigating problem, stand by.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> > >>>>>
> > >>>>>> dpavlov@
> > >>>>>
> > >>>>>> &gt; 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 next 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

Re: Code inspection

[Nikolay Izhikov <ni...@apache.org>]

Petr, we should have 1 configuration for project, may be 1 configuration
per programming language.

пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.weider@gmail.com:

> I was asking about how many build configuration is intended? One for all
> and multiple per module?
>
> With IDEA inspections it was going to be build configuration per module.
>
>
>
>
> > On 11 Feb 2019, at 11:24, Nikolay Izhikov <ni...@apache.org> wrote:
> >
> > Hello, Petr.
> >
> > Are you saying that we have not single build task? And each module builds
> > when it required? If yes, then I propose to create a task like "Licence
> > check" which will be run for every patch.
> >
> > My point is that violation of codestyle should be treated as hard as
> > compile error.
> >
> > пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com:
> >
> >> Is build configuration Inspections [Core] meant to transform into single
> >> all-modules check build configuration (without module subdivision)?
> >>
> >>
> >>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <ni...@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/1065-checkstyle-idea
> >>>
> >>> I propose do the following:
> >>>
> >>> 1. Migrate current checks to checkstyle.
> >>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite" suite. Ignite has
> >> to
> >>> fail to build if patch violates codestyle.
> >>>
> >>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <vo...@gmail.com>:
> >>>
> >>>> Hi,
> >>>>
> >>>> I also think that some warning from IDEA that some code style rule is
> >>>> violated is a must-have.
> >>>>
> >>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <oi...@gridgain.com>:
> >>>>>
> >>>>> Hi Maxim,
> >>>>>
> >>>>> I believe that whatever style checks we establish at Teamcity, we
> >> better
> >>>>> take care of making it easy for developers to find and fix violations
> >> in
> >>>>> their typical dev environment (for Ignite this means, in IDEA). I
> think
> >>>> it
> >>>>> is important that developers can maintain 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 just 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 checkstyle - I recommend keeping
> its
> >>>>> config file somewhere in the project under version control. I used to
> >>>>> maintain such a shared style config at one of past jobs and after
> some
> >>>>> experimenting it turned out most convenient to have it this way - so
> >> that
> >>>>> developers could easily assess and discuss style settings and keep
> >> track
> >>>> of
> >>>>> changes in these. (note how Kafka folks 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 community members. Moreover, this
> >>>>>> suite is no longer checks rules we previously 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 consider the Apache Kafka code style
> [5]
> >>>>>> way and configure for the Ignite project a maven-checkstyle-plugin
> >>>>>> with its own maven profile and run it simultaneously with other TC.
> We
> >>>>>> can also enable the previously configured inspection rules, so no
> >>>>>> coding style violations will be missed.
> >>>>>>
> >>>>>> I see some advantages of using a maven plugin:
> >>>>>> - an IDE agnostic way for code checks
> >>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> >>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> >>>>>> [3]
> >>>>
> >>
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> >>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> >>>>>> [5] https://github.com/apache/kafka/tree/trunk/checkstyle
> >>>>>>
> >>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> >>>>>
> >>>>>> mr.weider@
> >>>>>
> >>>>>> &gt; wrote:
> >>>>>>>
> >>>>>>> It seems there is bug in latest 2018.2 TeamCity
> >>>>>>> Bug is filed [1]
> >>>>>>>
> >>>>>>>
> >>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> >>>>>>>
> >>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> >>>>>
> >>>>>> mr.weider@
> >>>>>
> >>>>>> &gt; wrote:
> >>>>>>>>
> >>>>>>>> Investigating problem, stand by.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> >>>>>
> >>>>>> dpavlov@
> >>>>>
> >>>>>> &gt; 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 next step to fix it?
> >>>>>>>>>
> >>>>>>>>> Sincerely,
> >>>>>>>>> Dmitriy Pavlov
> >>>>>>>>> [cut]
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best regards,
> >>>> Ivan Pavlukhin
> >>>>
> >>
> >>
>
>

Re: Code inspection

[Petr Ivanov <mr...@gmail.com>]

I was asking about how many build configuration is intended? One for all and multiple per module?

With IDEA inspections it was going to be build configuration per module.




> On 11 Feb 2019, at 11:24, Nikolay Izhikov <ni...@apache.org> wrote:
> 
> Hello, Petr.
> 
> Are you saying that we have not single build task? And each module builds
> when it required? If yes, then I propose to create a task like "Licence
> check" which will be run for every patch.
> 
> My point is that violation of codestyle should be treated as hard as
> compile error.
> 
> пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com:
> 
>> Is build configuration Inspections [Core] meant to transform into single
>> all-modules check build configuration (without module subdivision)?
>> 
>> 
>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov <ni...@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/1065-checkstyle-idea
>>> 
>>> I propose do the following:
>>> 
>>> 1. Migrate current checks to checkstyle.
>>> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite" suite. Ignite has
>> to
>>> fail to build if patch violates codestyle.
>>> 
>>> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <vo...@gmail.com>:
>>> 
>>>> Hi,
>>>> 
>>>> I also think that some warning from IDEA that some code style rule is
>>>> violated is a must-have.
>>>> 
>>>> вс, 10 февр. 2019 г. в 01:58, oignatenko <oi...@gridgain.com>:
>>>>> 
>>>>> Hi Maxim,
>>>>> 
>>>>> I believe that whatever style checks we establish at Teamcity, we
>> better
>>>>> take care of making it easy for developers to find and fix violations
>> in
>>>>> their typical dev environment (for Ignite this means, in IDEA). I think
>>>> it
>>>>> is important that developers can maintain 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 just 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 checkstyle - I recommend keeping its
>>>>> config file somewhere in the project under version control. I used to
>>>>> maintain such a shared style config at one of past jobs and after some
>>>>> experimenting it turned out most convenient to have it this way - so
>> that
>>>>> developers could easily assess and discuss style settings and keep
>> track
>>>> of
>>>>> changes in these. (note how Kafka folks 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 community members. Moreover, this
>>>>>> suite is no longer checks rules we previously 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 consider the Apache Kafka code style [5]
>>>>>> way and configure for the Ignite project a maven-checkstyle-plugin
>>>>>> with its own maven profile and run it simultaneously with other TC. We
>>>>>> can also enable the previously configured inspection rules, so no
>>>>>> coding style violations will be missed.
>>>>>> 
>>>>>> I see some advantages of using a maven plugin:
>>>>>> - an IDE agnostic way for code checks
>>>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
>>>>>> [3]
>>>> 
>> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
>>>>>> [5] https://github.com/apache/kafka/tree/trunk/checkstyle
>>>>>> 
>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
>>>>> 
>>>>>> mr.weider@
>>>>> 
>>>>>> &gt; wrote:
>>>>>>> 
>>>>>>> It seems there is bug in latest 2018.2 TeamCity
>>>>>>> Bug is filed [1]
>>>>>>> 
>>>>>>> 
>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
>>>>>>> 
>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
>>>>> 
>>>>>> mr.weider@
>>>>> 
>>>>>> &gt; wrote:
>>>>>>>> 
>>>>>>>> Investigating problem, stand by.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
>>>>> 
>>>>>> dpavlov@
>>>>> 
>>>>>> &gt; 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 next step to fix it?
>>>>>>>>> 
>>>>>>>>> Sincerely,
>>>>>>>>> Dmitriy Pavlov
>>>>>>>>> [cut]
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best regards,
>>>> Ivan Pavlukhin
>>>> 
>> 
>> 

Re: Code inspection

[Nikolay Izhikov <ni...@apache.org>]

Hello, Petr.

Are you saying that we have not single build task? And each module builds
when it required? If yes, then I propose to create a task like "Licence
check" which will be run for every patch.

My point is that violation of codestyle should be treated as hard as
compile error.

пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.weider@gmail.com:

> Is build configuration Inspections [Core] meant to transform into single
> all-modules check build configuration (without module subdivision)?
>
>
> > On 11 Feb 2019, at 11:02, Nikolay Izhikov <ni...@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/1065-checkstyle-idea
> >
> > I propose do the following:
> >
> > 1. Migrate current checks to checkstyle.
> > 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite" suite. Ignite has
> to
> > fail to build if patch violates codestyle.
> >
> > вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <vo...@gmail.com>:
> >
> >> Hi,
> >>
> >> I also think that some warning from IDEA that some code style rule is
> >> violated is a must-have.
> >>
> >> вс, 10 февр. 2019 г. в 01:58, oignatenko <oi...@gridgain.com>:
> >>>
> >>> Hi Maxim,
> >>>
> >>> I believe that whatever style checks we establish at Teamcity, we
> better
> >>> take care of making it easy for developers to find and fix violations
> in
> >>> their typical dev environment (for Ignite this means, in IDEA). I think
> >> it
> >>> is important that developers can maintain 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 just 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 checkstyle - I recommend keeping its
> >>> config file somewhere in the project under version control. I used to
> >>> maintain such a shared style config at one of past jobs and after some
> >>> experimenting it turned out most convenient to have it this way - so
> that
> >>> developers could easily assess and discuss style settings and keep
> track
> >> of
> >>> changes in these. (note how Kafka folks 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 community members. Moreover, this
> >>>> suite is no longer checks rules we previously 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 consider the Apache Kafka code style [5]
> >>>> way and configure for the Ignite project a maven-checkstyle-plugin
> >>>> with its own maven profile and run it simultaneously with other TC. We
> >>>> can also enable the previously configured inspection rules, so no
> >>>> coding style violations will be missed.
> >>>>
> >>>> I see some advantages of using a maven plugin:
> >>>> - an IDE agnostic way for code checks
> >>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> >>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
> >>>> [3]
> >>
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> >>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> >>>> [5] https://github.com/apache/kafka/tree/trunk/checkstyle
> >>>>
> >>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> >>>
> >>>> mr.weider@
> >>>
> >>>> &gt; wrote:
> >>>>>
> >>>>> It seems there is bug in latest 2018.2 TeamCity
> >>>>> Bug is filed [1]
> >>>>>
> >>>>>
> >>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
> >>>>>
> >>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> >>>
> >>>> mr.weider@
> >>>
> >>>> &gt; wrote:
> >>>>>>
> >>>>>> Investigating problem, stand by.
> >>>>>>
> >>>>>>
> >>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> >>>
> >>>> dpavlov@
> >>>
> >>>> &gt; 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 next step to fix it?
> >>>>>>>
> >>>>>>> Sincerely,
> >>>>>>> Dmitriy Pavlov
> >>>>>>> [cut]
> >>>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Ivan Pavlukhin
> >>
>
>

Re: Code inspection

[Petr Ivanov <mr...@gmail.com>]

Is build configuration Inspections [Core] meant to transform into single all-modules check build configuration (without module subdivision)?


> On 11 Feb 2019, at 11:02, Nikolay Izhikov <ni...@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/1065-checkstyle-idea
> 
> I propose do the following:
> 
> 1. Migrate current checks to checkstyle.
> 2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite" suite. Ignite has to
> fail to build if patch violates codestyle.
> 
> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <vo...@gmail.com>:
> 
>> Hi,
>> 
>> I also think that some warning from IDEA that some code style rule is
>> violated is a must-have.
>> 
>> вс, 10 февр. 2019 г. в 01:58, oignatenko <oi...@gridgain.com>:
>>> 
>>> Hi Maxim,
>>> 
>>> I believe that whatever style checks we establish at Teamcity, we better
>>> take care of making it easy for developers to find and fix violations in
>>> their typical dev environment (for Ignite this means, in IDEA). I think
>> it
>>> is important that developers can maintain 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 just 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 checkstyle - I recommend keeping its
>>> config file somewhere in the project under version control. I used to
>>> maintain such a shared style config at one of past jobs and after some
>>> experimenting it turned out most convenient to have it this way - so that
>>> developers could easily assess and discuss style settings and keep track
>> of
>>> changes in these. (note how Kafka folks 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 community members. Moreover, this
>>>> suite is no longer checks rules we previously 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 consider the Apache Kafka code style [5]
>>>> way and configure for the Ignite project a maven-checkstyle-plugin
>>>> with its own maven profile and run it simultaneously with other TC. We
>>>> can also enable the previously configured inspection rules, so no
>>>> coding style violations will be missed.
>>>> 
>>>> I see some advantages of using a maven plugin:
>>>> - an IDE agnostic way for code checks
>>>> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504
>>>> [3]
>> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277
>>>> [5] https://github.com/apache/kafka/tree/trunk/checkstyle
>>>> 
>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
>>> 
>>>> mr.weider@
>>> 
>>>> &gt; wrote:
>>>>> 
>>>>> It seems there is bug in latest 2018.2 TeamCity
>>>>> Bug is filed [1]
>>>>> 
>>>>> 
>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504
>>>>> 
>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
>>> 
>>>> mr.weider@
>>> 
>>>> &gt; wrote:
>>>>>> 
>>>>>> Investigating problem, stand by.
>>>>>> 
>>>>>> 
>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
>>> 
>>>> dpavlov@
>>> 
>>>> &gt; 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 next step to fix it?
>>>>>>> 
>>>>>>> Sincerely,
>>>>>>> Dmitriy Pavlov
>>>>>>> [cut]
>>>>>> 
>>>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>> 
>> 
>> 
>> --
>> Best regards,
>> Ivan Pavlukhin
>> 

Re: Code inspection

[Nikolay Izhikov <ni...@apache.org>]

Hello, Maxim.

+1 from me for migrating to checkstyle.

Oleg, there is plugin for IDEA with 2mln downloads -
https://plugins.jetbrains.com/plugin/1065-checkstyle-idea

I propose do the following:

1. Migrate current checks to checkstyle.
2. Apply checks to all Ignite modules. Currently, 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 Apache Ignite" suite. Ignite has to
fail to build if patch violates codestyle.

вс, 10 февр. 2019 г. в 07:54, Павлухин Иван <vo...@gmail.com>:

> Hi,
>
> I also think that some warning from IDEA that some code style rule is
> violated is a must-have.
>
> вс, 10 февр. 2019 г. в 01:58, oignatenko <oi...@gridgain.com>:
> >
> > Hi Maxim,
> >
> > I believe that whatever style checks we establish at Teamcity, we better
> > take care of making it easy for developers to find and fix violations in
> > their typical dev environment (for Ignite this means, in IDEA). I think
> it
> > is important that developers can maintain 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 just 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 checkstyle - I recommend keeping its
> > config file somewhere in the project under version control. I used to
> > maintain such a shared style config at one of past jobs and after some
> > experimenting it turned out most convenient to have it this way - so that
> > developers could easily assess and discuss style settings and keep track
> of
> > changes in these. (note how Kafka folks 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 community members. Moreover, this
> > > suite is no longer checks rules we previously 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 consider the Apache Kafka code style [5]
> > > way and configure for the Ignite project a maven-checkstyle-plugin
> > > with its own maven profile and run it simultaneously with other TC. We
> > > can also enable the previously configured inspection rules, so no
> > > coding style violations will be missed.
> > >
> > > I see some advantages of using a maven plugin:
> > > - an IDE agnostic way for code checks
> > > - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > > [2] https://youtrack.jetbrains.com/issue/TW-58504
> > > [3]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > > [4] https://issues.apache.org/jira/browse/IGNITE-11277
> > > [5] https://github.com/apache/kafka/tree/trunk/checkstyle
> > >
> > > On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
> >
> > > mr.weider@
> >
> > > &gt; wrote:
> > >>
> > >> It seems there is bug in latest 2018.2 TeamCity
> > >> Bug is filed [1]
> > >>
> > >>
> > >> [1] https://youtrack.jetbrains.com/issue/TW-58504
> > >>
> > >> > On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
> >
> > > mr.weider@
> >
> > > &gt; wrote:
> > >> >
> > >> > Investigating problem, stand by.
> > >> >
> > >> >
> > >> >> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
> >
> > > dpavlov@
> >
> > > &gt; 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 next step to fix it?
> > >> >>
> > >> >> Sincerely,
> > >> >> Dmitriy Pavlov
> > >> >>[cut]
> > >> >
> > >>
> >
> >
> >
> >
> >
> > --
> > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

Re: Code inspection

[Павлухин Иван <vo...@gmail.com>]

Hi,

I also think that some warning from IDEA that some code style rule is
violated is a must-have.

вс, 10 февр. 2019 г. в 01:58, oignatenko <oi...@gridgain.com>:
>
> Hi Maxim,
>
> I believe that whatever style checks we establish at Teamcity, we better
> take care of making it easy for developers to find and fix violations in
> their typical dev environment (for Ignite this means, in IDEA). I think it
> is important that developers can maintain 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 just 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 checkstyle - I recommend keeping its
> config file somewhere in the project under version control. I used to
> maintain such a shared style config at one of past jobs and after some
> experimenting it turned out most convenient to have it this way - so that
> developers could easily assess and discuss style settings and keep track of
> changes in these. (note how Kafka folks 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 community members. Moreover, this
> > suite is no longer checks rules we previously 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 consider the Apache Kafka code style [5]
> > way and configure for the Ignite project a maven-checkstyle-plugin
> > with its own maven profile and run it simultaneously with other TC. We
> > can also enable the previously configured inspection rules, so no
> > coding style violations will be missed.
> >
> > I see some advantages of using a maven plugin:
> > - an IDE agnostic way for code checks
> > - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> > [2] https://youtrack.jetbrains.com/issue/TW-58504
> > [3]https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> > [4] https://issues.apache.org/jira/browse/IGNITE-11277
> > [5] https://github.com/apache/kafka/tree/trunk/checkstyle
> >
> > On Fri, 21 Dec 2018 at 16:03, Petr Ivanov &lt;
>
> > mr.weider@
>
> > &gt; wrote:
> >>
> >> It seems there is bug in latest 2018.2 TeamCity
> >> Bug is filed [1]
> >>
> >>
> >> [1] https://youtrack.jetbrains.com/issue/TW-58504
> >>
> >> > On 19 Dec 2018, at 11:31, Petr Ivanov &lt;
>
> > mr.weider@
>
> > &gt; wrote:
> >> >
> >> > Investigating problem, stand by.
> >> >
> >> >
> >> >> On 18 Dec 2018, at 19:41, Dmitriy Pavlov &lt;
>
> > dpavlov@
>
> > &gt; 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 next step to fix it?
> >> >>
> >> >> Sincerely,
> >> >> Dmitriy Pavlov
> >> >>[cut]
> >> >
> >>
>
>
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/



-- 
Best regards,
Ivan Pavlukhin

Re: Code inspection

[oignatenko <oi...@gridgain.com>]

Hi Maxim,

I believe that whatever style checks we establish at Teamcity, we better
take care of making it easy for developers to find and fix violations in
their typical dev environment (for Ignite this means, in IDEA). I think it
is important that developers can maintain 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 just 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 checkstyle - I recommend keeping its
config file somewhere in the project under version control. I used to
maintain such a shared style config at one of past jobs and after some
experimenting it turned out most convenient to have it this way - so that
developers could easily assess and discuss style settings and keep track of
changes in these. (note how Kafka folks 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 community members. Moreover, this
> suite is no longer checks rules we previously 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 consider the Apache Kafka code style [5]
> way and configure for the Ignite project a maven-checkstyle-plugin
> with its own maven profile and run it simultaneously with other TC. We
> can also enable the previously configured inspection rules, so no
> coding style violations will be missed.
> 
> I see some advantages of using a maven plugin:
> - an IDE agnostic way for code checks
> - can be used with different CI and build 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=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> [2] https://youtrack.jetbrains.com/issue/TW-58504
> [3]https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
> [4] https://issues.apache.org/jira/browse/IGNITE-11277
> [5] https://github.com/apache/kafka/tree/trunk/checkstyle
> 
> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov <

> mr.weider@

> > wrote:
>>
>> It seems there is bug in latest 2018.2 TeamCity
>> Bug is filed [1]
>>
>>
>> [1] https://youtrack.jetbrains.com/issue/TW-58504
>>
>> > On 19 Dec 2018, at 11:31, Petr Ivanov <

> 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 next step to fix it?
>> >>
>> >> Sincerely,
>> >> Dmitriy Pavlov
>> >>[cut]
>> >
>>





--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/