commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chas Honton <>
Subject Re: [ALL] Automated requirements (e.g. CheckStyle)?
Date Wed, 09 Aug 2017 01:49:44 GMT
Since most of us work in an IDE, the "wasted" time of checkstyle for every build is negligible.
At my day job, all code is automatically reformatted as part of the build. It's just another
step along with PMD, CPD, findbugs, sonar, jacoco, junit, and a few other static analyses.
The more we automate, the less we need to remember and the higher the quality of our code.


> On Aug 8, 2017, at 4:13 PM, Gilles <> wrote:
> Hello.
>> On Wed, 9 Aug 2017 00:20:00 +0200, Karl-Philipp Richter wrote:
>> Hi,
>>> Am 07.08.2017 um 15:09 schrieb Gilles:
>>> Less work for the maintainers is good. :-)
>>> By "taking time" I meant that validating should not be enforced when
>>> calling "mvn compile" or "mvn test".
>> I wouldn't worry about the time consumption of the validation even if
>> it's run by every dev before very compilation since the sum of
>> conversation parts in patch/PR discussion in the form of "LGTM, except
>> for the indentation at line xy" - "OK, I fixed that now" - "Oh, no wait,
>> I forgot the trailing space at line yz" - ... - merged takes an infinite
>> more of time and energy.
> I agree, but that is with respect to interaction with someone not used
> to the coding style/rules; what I meant is that when doing one's "own"
> work, one shouldn't have to wait for CheckStyle at every compilation,
> when you know that you'll fix the missing doc _after_ fixing the code.
>> Regarding the phase where checkstyle should be run I have some
>> additional thoughts to my initial post:
>>  * If running checkstyle will be enforced the only phase that makes
>> sense is `validate` because you don't won't to build something that's
>> invalid because it's somehow unlogical and a waiste of time if you don't
>> fail the build as early as possible. In order to avoid annoyance for
>> users who aren't used to fix checkstyle errors before being able to
>> build I'd suggest a profile with deactivated checkstyle which allows
>> that rather an putting checkstyle in a separate profile.
> IIUC, that would be fine (since it takes care of the above scenario).
>>  * Running checkstyle in the site or any other reporting phase is in
>> Maven speak afaik "show what might be wrong with my build given the fact
>> that I consider it passing after compilation, unit and integration tests
>> passed" or "show me some statistics about style issues - 150, wow that's
>> 12 less than last build".
> That's what we've done up to now; and the number of errors is supposed
> to be zero before a release.  But I agree that the risk of a lot of work
> for the RM would be reduced by enforcing checks at least before committing
> to the "master" branch.
> Is anyone objecting?
> I think that the profile should be defined in the "parent" POM.
> Can someone make the necessary additions?
> Thanks,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message