[MPOM-349] Apply spotless to check/reformat code + poms

[gnodet]

JIRA issue: https://issues.apache.org/jira/browse/MPOM-349

• [MPOM-349] Apply spotless to check/reformat code + poms
• [MPOM-349] Reformat poms

Depends on apache/maven-shared-resources#5

Discussed on

• https://lists.apache.org/thread/ok9qdl1w92f9fhdkz3tmc5f65ytpppqpD
• https://lists.apache.org/thread/md6do2dllt9cv4s311y3ky6245xmvd0w

The PR includes the following changes:

• add spotless with palantir formatter (120 column, 4 spaces indent) + pom formatter (2 spaces indent + pom ordering)
• disable checkstyle rules enforced by the formatter
• enable formatter check (code style validation) by default
• provide a format profile (activated with the format property) to apply formatting rules automatically
• reformat poms to pass the new checks (in a subsequent commit to ease review)

[olamy]

LGTM but if we move to spotless. I would remove checkstyle:check as well as we do not need really to check sources style twice during the build....
And it's a bit confusing as when testing this pom with m-war-p, checkstyle:check is passing but not `spotless:check'

[bmarwell]

Just some nits, otherwise+1

[olamy]

see #82 (comment)

[gnodet]

LGTM but if we move to spotless. I would remove checkstyle:check as well as we do not need really to check sources style twice during the build....
And it's a bit confusing as when testing this pom with m-war-p, checkstyle:check is passing but not `spotless:check'

@olamy Checkstyle checks method length, file length, qualifier order, parameter numbers, field/method ordering, etc... Those won't be checked by pure code style validation. I don't really see the value for removing those checks.

[olamy]

LGTM but if we move to spotless. I would remove checkstyle:check as well as we do not need really to check sources style twice during the build....
And it's a bit confusing as when testing this pom with m-war-p, checkstyle:check is passing but not `spotless:check'

@olamy Checkstyle checks method length, file length, qualifier order, parameter numbers, field/method ordering, etc... Those won't be checked by pure code style validation. I don't really see the value for removing those checks.

ah right sorry.
but still everything concerning style in checkstyle (sorry but the name is confusing ;) ) can be removed.
I mean such https://github.com/apache/maven-shared-resources/blob/f9f3527cd3546e208f5d13e1ca37ba763bac6d0c/src/main/resources/config/maven_checks.xml#L61

nothing really urgent as long as it's in sync.

[gnodet]

LGTM but if we move to spotless. I would remove checkstyle:check as well as we do not need really to check sources style twice during the build....
And it's a bit confusing as when testing this pom with m-war-p, checkstyle:check is passing but not `spotless:check'

I've disabled the checkstyle checks that could conflict with the ones checked by spotless, so what you see is expected. The remaining checkstyle checks should be related to non stylistic issues: naming, ordering, javadoc, method/file length, modifiers ordering, inner assignment, magic numbers, etc... So those checks can not really be fixed without refactoring the code. Makes more sense ?

[gnodet]

LGTM but if we move to spotless. I would remove checkstyle:check as well as we do not need really to check sources style twice during the build....
And it's a bit confusing as when testing this pom with m-war-p, checkstyle:check is passing but not `spotless:check'

@olamy Checkstyle checks method length, file length, qualifier order, parameter numbers, field/method ordering, etc... Those won't be checked by pure code style validation. I don't really see the value for removing those checks.

ah right sorry. but still everything concerning style in checkstyle (sorry but the name is confusing ;) ) can be removed. I mean such https://github.com/apache/maven-shared-resources/blob/f9f3527cd3546e208f5d13e1ca37ba763bac6d0c/src/main/resources/config/maven_checks.xml#L61

nothing really urgent as long as it's in sync.

Yes, the problem is that I was fearing a bit removing those checks from maven-shared-resources. If a projet upgrades this dependency but does not use the latest parent, it will have some checks not enforced anymore. But yes, at some point, it should be synced.

[slawekjaranowski]

We should use release version.

[gnodet]

Argh, well spotted. I think it may be easier to put the removal of the related check styles in the checkstyle rules that maven-shared-resources provides then. I'll raise a PR there.

[gnodet]

apache/maven-shared-resources#5