On Wed, 9 Aug 2017 10:56:47 +0100, sebb wrote:
On 9 August 2017 at 03:57, Gilles <gil...@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 <gil...@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-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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
