* Update Gradle Wrapper to 8.2 (#96686)
- Convention usage has been deprecated and was fixed in our build files
- Fix test dependencies and deprecation
We use `between(x, y)` calls with `switch` statements in tests to
randomize test behaviour. However, some usages define `case` statements
that can never execute, because the `case` value is outside the range
defined by the `between` call.
Write a rule that inspects the switches and the cases, and fails on the
broken cases. This rule checks `between`, `randomIntBetween` and
`randomInt`.
* Port javadoc configuration logic into a binary plugin (#86471)
Also adding test coverage and fixing certain issues we stumbled into
when resolving project dependencies of compileClasspath we need to use allDependencies instead of dependencies as usually no dependencies are added directly to compileClasspath but via implementation, compileonly and api and friends
Fixed javadoc setup for projects using shadowed dependencies via shadow plugin
Fixed dealing with skipped javadoc tasks in referenced dependent projects.
In general this PR only fixes expected javadoc generation as it was intended before this PR.
This also contains some tweaks to our gradle integration test fixtures for setting up and debugging test projects
# Conflicts:
# build-tools-internal/src/integTest/groovy/org/elasticsearch/gradle/fixtures/AbstractRestResourcesFuncTest.groovy
# build-tools-internal/src/integTest/groovy/org/elasticsearch/gradle/internal/test/rest/InternalYamlRestTestPluginFuncTest.groovy
# build-tools-internal/src/integTest/groovy/org/elasticsearch/gradle/internal/test/rest/YamlRestCompatTestPluginFuncTest.groovy
# build-tools/src/integTest/groovy/org/elasticsearch/gradle/TestClustersPluginFuncTest.groovy
# build-tools/src/testFixtures/groovy/org/elasticsearch/gradle/fixtures/AbstractGradleFuncTest.groovy
* Fix merge conflicts for backporting
Some architectures provide non-standard output in /proc/cpuinfo.
Specifically, AWS graviton. In case we can't properly calculate physical
cpu cores via the standard method just fallback to using the JDK-backed
implementation.
* Replace getProject() references with injected services in task implementations where possible (#81681)
- Rework task implementations to avoid project usage at execution time
- In general usages of getProject() within a task should be avoided as it is not compatible
with gradle configuration cache. Related to #57918
Co-authored-by: Mark Vieira <portugee@gmail.com>
* Make ForbiddenApisPrecommitPlugin plugin Gradle 8.0 compatible
* Fix deprecations on ignoring empty folders for task inputs
* Update Gradle wrapper to 7.4 GA
Checkstyle 9.3 has been released, and contains a fix for the memory
problems we saw in previous versions. Upgrade to this version.
Note that the IDEA config has also been updated, but the plugin
doesn't yet have 9.3 as an option according to the release notes.
This shouldn't be a problem.
- Updates checkstyle to 8.45.1
- This was update was triggered by us running into checkstyle/checkstyle#9897 We do not update to latest 9.x release yet as we see a performance decrease when running precommit with this. likely related to checkstyle/checkstyle#10934
Thanks to https://bugs.eclipse.org/bugs/show_bug.cgi?id=574437,
we've run into a situation where Spotless is incorrectly formatting
a particular piece of syntax (due the underlying Eclipse bug). We
were able to turn off formatting of this syntax using `// @formatter:off`
and `// @formatter:on`, but there was a further problem. We configure
IntelliJ to use the Eclipse formatter plugin, but this doesn't
respect the `@formatter` tags since these are set at the Spotless
level, not the Eclipse formatter level. Note that these tags aren't
set in the Eclipse formatter config, because there we use `// tag::`
and `// end::` in order to avoid reformatting docs snippets, which
have a much narrower line width.
What a mess.
So, to get around all this, drop the `@formatter` tags and tweak
our custom `SnippetLengthCheck` Checkstyle rule so that
`// tag:noformat` regions are not subject to the narrower line length
check, but are still exempt from formatting.
Change our fork of `HiddenFieldCheck` rule to allow it to ignore
shadowed variables for methods shorter than a configured minimim line
count. While this technically defeats the point of the rule, in practice
short methods are easier to verify by eye, compared to longer methods
where accidentally referencing the wrong variable is harder to spot.
Following this, revert some changes in the EQL code which were required
to pass the `HiddenField` check before the `minLineCount` change.
Additionally, introduce a mechanism for ignoring shadowed variables when
used created a new object. This allowed us to ignore variables in usages
of e.g. `ConstructingObjectParser` whose purpose, as the name suggests,
is to build objects, and object shadows variables in the course of
building objects.
Part of #19752. Fix more instances where local variable names were
shadowing field names. Also expand the possible method names that are
skipped when checking for shadowed vars, and allow shadowed vars in
builder classes.
Part of #19752. Fix more instances where local variable names were
shadowing field names.
Also modify our fork of HiddenFieldCheck to add the ignoreConstructorBody
and ignoredMethodNames parameters, so that the check can ignore
more matches.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* Fix shadowed vars pt4 (#80842)
Part of #19752. Fix more instances where local variable names were shadowing field names.
* Fix shadowed vars pt5 (#80855)
Part of #19752. Fix more instances where local variable names were shadowing field names.
* Formatting
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This is an attempt at resolving, or at least reducing the prevalence of
#77837. A more robust solution is probably required, but this should
help reduce this problem since we now apply spotless to about 90 fewer
subprojects.
Part of #19752.
Fix a number of cases of shadows vars under `client/rest-high-level`. As
part of this, fork the Checkstyle `HiddeFieldCheck` class so that it
understand the pattern of settings with no "set" prefix.
The spotless plugin applies the gradle base plugin which results in
building all artifacts in the bwc projects when just running build. This
is not intended and happened as part of work on #78910 The correct fix
is to not apply the base plugin in the spotless plugin IMO. We will work
on getting that fix upstream to the third party gradle plugin Meanwhile
we just ignore bwc projects for our formatting as they also have no
source available anyhow. This fixes#79606 when backported to 7.x
* Move xcontent filtering tests (#79298)
* Move xcontent filtering tests
Moves the xcontent filtering tests to the xcontent project because its
testing code *in* the xcontent project.
* More clear
* Spotless
* Fixup
Java9 added a number of features that are useful to improve compression
and decompression. These include the Arrays#mismatch method and
VarHandles. This commit adds compression tools forked from the java-lz4
library which include these improvements. We hope to contribute these
changes back to the original project, however the project currently
supports Java7 so this is not possible at the moment.
Our spotless configuration wasn't being applied to `build-tools`
and `build-tools-internal`. Move the Spotless configuration to a
Java plugin in `build-conventions`, and apply it everywhere.
This resulted in a lot more Java files being subject to formatting,
so I added more exclusions to the list.
Also remove the `paddedCell` stuff, we've never needed it.
* Fix minimum runtime version for build tools (#78998)
Resolve version from minimumRuntimeVersion file
* Use java 11 compatibility for build tool projects
- Use file property and conventions to avoid afterEvaluate hook
- Simplify root build script
- One little step closer to configuration cache compliance
* Resolve system properties in build scripts via provider factory (#76199)
This allows tracking system properties used in the build configuration and brings us
one step closer to be gradle configuration cache compliant.
* Fix system property resolution at configuration time (#78669)
This fixes system property resolution when running the build with --configuration-cache
One step closer to make use of configuration cache
* Make PublishPlugin gradle configuration cache compliant
for using --configuration-cache we need to remove some usages of the mutable project instance
* Polishing
this has been deprecated and will be removed in Gradle 8.0. We use
JavaPluginExtension instead from now on.
Co-authored-by: Rene Groeschke <rene@elastic.co>