Am 02.08.2016 um 08:54 schrieb Dennis Kieselhorst: > Am 01.08.2016 um 21:31 schrieb Oliver Heger: >> Am 31.07.2016 um 22:24 schrieb Matt Sicker: >>> Fixing all the checkstyle errors first is kind of a prerequisite to >>> enabling it by default. >>> >>> On 31 July 2016 at 15:10, Charles Honton <c...@honton.org> wrote: >>> >>>> Why wouldn’t we want build to fail early if incorrect style is used? >> In this special case, the build was broken on JDK 1.6 which is blocking >> the configuration 2.1 release. >> >> In general, IMHO it is too strict to let the build fail because a >> bracket is set incorrectly or something like this. It is fine if this >> generates a warning, and these warnings can be fixed before a release. >> But I do not want to be forced to fix all style violations at any time. >> Especially, as such violations will creep in nevertheless (somebody does >> a quick commit without running the full build) and then cause problems >> in the future. >> > I've changed it after committing with wrong codestyle. Before the > checkstyle config was just in the reporting section, so only just for > site generation. When I was running mvn checkstyle:check before my > commit, I got thousands of violations as a default ruleset was applied. > > Now you immediately see during normal build that something is wrong. Of > course the build was passing after the change. During the release build > we just discovered that generated sources were checked as well when > using Maven 3.2.5 and JDK 1.6, but not checked when using Maven 3.3.9 > and JDK 1.7/ 1.8. This is now fixed by an exclude for the generated sources. > > I prefer that the build fails as warnings are often ignored. If we > change it, we should at least fail on Jenkins (using a ci profile).
Well, for me style is not that important. (We cannot even agree on a common style for the Commons project.) Therefore, seeing the violations in the report is sufficient for me. Other reports are IMHO more important, e.g. findbugs or RAT (for legal reasons). Would we also let the build fail when here violations are found? I fear that such strict rules will also be an obstacle for contributors: Somebody wants to play with the code, tries something out, and the build fails because of unrelated stuff. Oliver > > Regards > Dennis > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
