commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [ALL] Automated requirements (e.g. CheckStyle)?
Date Sat, 12 Aug 2017 00:03:07 GMT
On Wed, 9 Aug 2017 10:56:47 +0100, sebb wrote:
> On 9 August 2017 at 03:57, Gilles <gilles@harfang.homelinux.org> 
> wrote:
>> On Tue, 8 Aug 2017 18:49:44 -0700, Chas Honton wrote:
>>>
>>> Since most of us work in an IDE, the "wasted" time of checkstyle 
>>> for
>>> every build is negligible.
>
> IDEs vary in how easy it is to set up the checks to agree with the
> project settings.
> And IDEs vary in the impact on the build time.

Once there is a profile (in "parent"?) and a documented rule
saying "run <some mvn command> and the generated report should
be clean before the PR will be considered for inclusion", why
do we care about IDE x or y?

Gilles

>>
>> It's not just the wasted time of running the tool (which might
>> well be negligible), it's the forcing of e.g. documenting a code
>> that might turn out to be transient on the path to a complete
>> fix.
>>
>>> 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.
>>
>>
>> That's not always the case: I don't particularly like the "feature"
>> of IDEs that automatically inserts Javadoc templates:
>>
>> /**
>>  *
>>  *
>>  * @param a
>>  * @param b
>>  * @return int
>>  */
>> public int doSomething(int a, int b) {
>>   // ...
>> }
>>
>> Which then often remain useless as actual documentation. ;-)
>>
>>
>> Regards,
>> Gilles
>>
>>
>>>
>>> Chas
>>>
>>>> On Aug 8, 2017, at 4:13 PM, Gilles <gilles@harfang.homelinux.org> 
>>>> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message