This commit renames a few of the most recent TransportVersion constants
to have meaningful names. Going forward all constants should have
meaningful names. Since the names will now be unique, the uuid is no
longer needed to force merge conflicts, so they are removed.
We have an internal policy about contributions which target unsupported
platforms but this is not spelled out in the contributing guide. This
commit adds the missing info.
Relates #93341
This change adds an optional step to the CONTRIBUTING.md docs on setting up
automatic code formatting to add it as a save action. This can help avoiding
running into spotless check errors later.
External users tend to edit the changelog, which causes build errors for instance when the area is modified, and causes sync problems if later e.g. the title of the PR is updated.
* Convert disk watermarks to RelativeByteSizeValues
Similar to the existing watermark setting for the frozen tier.
Pre-requisite for PR 88639 that plans to introduce max headroom
settings for the disk watermarks, similar to the frozen tier max
headroom setting.
* Add changelog
* Revert 20gb to 20GB
* Make formatNoTrailingZerosPercent non static
* ByteSizeValue.MINUS_ONE
* Remove getMinimumTotalSizeForBelowWatermark
* Remove comment
* Fix minor stuff
* Make parsing of RelativeByteSizeValue faster
Mimicks older definitelyNotPercentage function
* Remove Locale from Strings.format
* More MINUS_ONE
ParameterizedMessage will not be part of the new ES logging API and therefore should not be used.
java.util.Supplier and String.format should be used instead.
this commit adds ParameterizedMessage to forbidden api
relates #86549
This commit removes the remaining ParameterizedMessages that take a
single argument, this time where the argument contains method calls.
This was again done almost entirely through find/replace with regex in
IntelliJ.
relates #86549
This commit converts most ParameterizedMessages which take one argument
to direct logging messages. This was done with regex search/replace in
IntelliJ. It does omits if those single arguments have any parenthesis
(cast or method call). Those will be done in a followup.
relates #86549
Replace the no-args LogManager::getLogger calls with the single-arg
variant that accepts a j.l.Class reference, which avoids the stack walk
of the no-args variant. The no-args variant determines the caller's
class by looking at the stack frame two positions from itself. The use
of the 1-args variant is more explicit and avoids the need for the stack
walk, while retaining the very same behaviour. Standardizing on the
1-args variant will reduce the need to have different ways to retrieve
logger references.
Logging is important, but today we don't have any written guidance about
how we do it in Elasticsearch so contributors struggle to make an
informed decision about how to do it right. This commit adds some
guidance on logging to the contribution guide.
* Update CONTRIBUTING.md
Manual steps in the Formatting section to setup ECF did not work for me.
Added alternative steps to import build-conventions/formatterConfig.xml
into IntelliJ 2021.2.3 Ultimate on Windows.
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.
I believe ES gets tested now against only JDK 8, 11, and 17, so you would need to have only `JAVA8_HOME`, `JAVA11_HOME`, and `JAVA17_HOME` set up in order to run the tests locally.
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.
This introduces a general document to track guidelines for working on and with
the elasticsearch gradle build
Co-authored-by: Rory Hunter <pugnascotia@users.noreply.github.com>
Change the formatter config to sort / order imports, and reformat the
codebase. We already had a config file for Eclipse users, so Spotless now
uses that.
The "Eclipse Code Formatter" plugin ought to be able to use this file as
well for import ordering, but in my experiments the results were poor.
Instead, use IntelliJ's `.editorconfig` support to configure import
ordering.
I've also added a config file for the formatter plugin.
Other changes:
* I've quietly enabled the `toggleOnOff` option for Spotless. It was
already possible to disable formatting for sections using the markers
for docs snippets, so enabling this option just accepts this reality
and makes it possible via `formatter:off` and `formatter:on` without
the restrictions around line length. It should still only be used as
a very last resort and with good reason.
* I've removed mention of the `paddedCell` option from the contributing
guide, since I haven't had to use that option for a very long time. I
moved the docs to the spotless config.
The build has been updated to require JDK15 for compilation but the
contributing docs were out of date. This commit updates the docs to
have the correct JDK requirement.
For configuring Checkstyle, the `CONTRIBUTING.md` guide said to point
the plugin at a jar file under `buildSrc/build/distributions`, but this
directory isn't guaranteed to exist, and gets removed by running the
`clean` task.
Instead, refer to a path under `buildSrc/build-bootstrap`, which will
always exist.
It turns out you can configure custom Checkstyle rules using the plugin
for IntelliJ, you just have to tell the plugin where to find the code.
Therefore, update the contributing docs with the necessary process.
Also fork the Checkstyle rule `MissingJavadocTypeCheck` so that we can
disable it for test classes. While it's useful to describe test cases in
test methods' Javadoc, this is somewhat less true for test classes
themselves.
As per the new licensing change for Elasticsearch and Kibana this commit
moves existing Apache 2.0 licensed source code to the new dual license
SSPL+Elastic license 2.0. In addition, existing x-pack code now uses
the new version 2.0 of the Elastic license. Full changes include:
- Updating LICENSE and NOTICE files throughout the code base, as well
as those packaged in our published artifacts
- Update IDE integration to now use the new license header on newly
created source files
- Remove references to the "OSS" distribution from our documentation
- Update build time verification checks to no longer allow Apache 2.0
license header in Elasticsearch source code
- Replace all existing Apache 2.0 license headers for non-xpack code
with updated header (vendored code with Apache 2.0 headers obviously
remains the same).
- Replace all Elastic license 1.0 headers with new 2.0 header in xpack.
Storing the generated config in the `build` dir meant that it could be
removed for various reasons, which causes e.g. IntelliJ to pop up
dialog, and is a mild annoyance. Instead, write the file to the project
root.
Also inline the path to the suppressions config, which removes a step
from the setup instructions.
With a few changes, our checkstyle config can be used by e.g. IntelliJ's
Checkstyle plugin. Add a task to generate this file automatically, and
create the necessary IntelliJ config to use it.
Also add a line-length setting to .editorconfig.
The review phase is an important part of contributing to Elasticsearch, but we
do not mention it in our instructions to contributors. This commit adds some
notes on how contributions are reviewed and describes some common reasons for
rejection.
Co-authored-by: Colin Goodheart-Smithe <colings86@users.noreply.github.com>
