config

Signed-off-by: Paul Merlin <paul@gradle.com>

- EqualsHashCode is now stricter and emits warnings for classes that

implement `hashCode()` but not `equals(Object)`.

- NoWhitespaceBefore now also checks for space before varargs ellipses.

There was a duplicate MethodTypeParameterName rule in checkstyle config, leading

to the wrong rule being used (the one that prevents MULTILETTER type variables).

Now that there are rules specific to integration tests, we have a dedicated

configuration file. This should avoid some accidental noise, and removes

the need to check for `Integration` in the test name, which helped discover

a few more problems.

This commits adds a CodeNarc rule which, for now, only looks for usages of

`result.output.contains(...)` and will report that as an incorrect usage of test fixtures,

because we should either use `outputContains(...)` or `failure.assertHasCause(...)`.

More usages can be added easily.

This rule is deeply annoying, as it forces the operators on newlines. Code generation typically

uses the opposite pattern, making it extremely simple to break the rule. Since it doesn't really

matter, disable the rule and let us work.

- Created init-scripts and shared-with-buildSrc sub directories

- Renamed a couple of scripts from camel case to kebap case

- Moved classycle resources to config directory

- Migrated build-scan-init script to Kotlin

Signed-off-by: Daniel Lacasse <daniel@gradle.com>

We like to be explicit. Please checkstyle, stop nagging us with this not so smart rule.

Move Java sources back to src/main/java

+review REVIEW-6526

This reverts commit c6cd884e1a8889fb25d26dfcfdfa79d896835e11.

This commit adds support for API dependencies in the generated pom file when using the `maven-publish` plugin.

It refactors the `Usage` class to make it public, and extensible by users. Then the legacy internal `Usage` class,

which was only used by the publishing plugin, has been updated to use `Usage` as a member, instead of being directly

the usage. This allows us to map configurations to usages more precisely.

- The `compile` scope of the generated pom file consists of the `api` dependencies.

- The `runtime` scope of the generated pom file consists of the old `runtime` dependencies *and* `runtimeElements` dependencies

With this setup, the new publishing plugin is now closer to the reality than the old Maven publishing plugin.

There are no Groovy sources left, so there's no need to keep these files in src/main/groovy. We can also save build time by only invoking a single compiler instead of two for these projects.