lint

Signed-off-by: Gregor Zeitlinger <[email protected]>

Author: zeitlinger

docs/content/exporters/httpserver.md

@@ -14,8 +14,8 @@ HTTPServer server = HTTPServer.builder()
 ```
 
 By default, `HTTPServer` binds to any IP address, you can change this with
-[hostname()](</client_java/api/io/prometheus/metrics/exporter/httpserver/HTTPServer.Builder.html#hostname(java.lang.String)>)
-or [inetAddress()](</client_java/api/io/prometheus/metrics/exporter/httpserver/HTTPServer.Builder.html#inetAddress(java.net.InetAddress)>).
+[hostname()](</client_java/api/io/prometheus/metrics/exporter/httpserver/HTTPServer.Builder.html#hostname(java.lang.String)>) <!-- editorconfig-checker-disable-line -->
+or [inetAddress()](</client_java/api/io/prometheus/metrics/exporter/httpserver/HTTPServer.Builder.html#inetAddress(java.net.InetAddress)>). <!-- editorconfig-checker-disable-line -->
 
 `HTTPServer` is configured with three endpoints:
 
@@ -24,7 +24,7 @@ or [inetAddress()](</client_java/api/io/prometheus/metrics/exporter/httpserver/H
 - `/` the default handler is a static HTML page.
 
 The default handler can be changed
-with [defaultHandler()](</client_java/api/io/prometheus/metrics/exporter/httpserver/HTTPServer.Builder.html#defaultHandler(com.sun.net.httpserver.HttpHandler)>).
+with [defaultHandler()](</client_java/api/io/prometheus/metrics/exporter/httpserver/HTTPServer.Builder.html#defaultHandler(com.sun.net.httpserver.HttpHandler)>). <!-- editorconfig-checker-disable-line -->
 
 ## Authentication and HTTPS
 
@@ -33,7 +33,7 @@ with [defaultHandler()](</client_java/api/io/prometheus/metrics/exporter/httpser
 - [httpsConfigurator()](</client_java/api/io/prometheus/metrics/exporter/httpserver/HTTPServer.Builder.html#httpsConfigurator(com.sun.net.httpserver.HttpsConfigurator)>)
   is for configuring HTTPS.
 
-You can find an example of authentication and SSL in the [jmx_exporter](https://github.com/prometheus/jmx_exporter).
+You can find an example of authentication and SSL in the [jmx_exporter](https://github.com/prometheus/jmx_exporter). <!-- editorconfig-checker-disable-line -->
 
 ## Properties
 

docs/content/exporters/pushgateway.md

@@ -3,11 +3,14 @@ title: Pushgateway
 weight: 5
 ---
 
-The [Prometheus Pushgateway](https://github.com/prometheus/pushgateway) exists to allow ephemeral and batch jobs to expose their metrics to Prometheus.
-Since these kinds of jobs may not exist long enough to be scraped, they can instead push their metrics to a Pushgateway.
+The [Prometheus Pushgateway](https://github.com/prometheus/pushgateway) exists to allow ephemeral
+and batch jobs to expose their metrics to Prometheus.
+Since these kinds of jobs may not exist long enough to be scraped, they can instead push their
+metrics to a Pushgateway.
 The Pushgateway then exposes these metrics to Prometheus.
 
-The [PushGateway](/client_java/api/io/prometheus/metrics/exporter/pushgateway/PushGateway.html) Java class allows you to push metrics to a Prometheus Pushgateway.
+The [PushGateway](/client_java/api/io/prometheus/metrics/exporter/pushgateway/PushGateway.html) Java
+class allows you to push metrics to a Prometheus Pushgateway.
 
 ## Example
 
@@ -97,7 +100,8 @@ The `PushGatewayTestApp` in `integration-tests/it-pushgateway` has a complete ex
 
 ## SSL
 
-The [PushGateway](/client_java/api/io/prometheus/metrics/exporter/pushgateway/PushGateway.html) supports SSL.
+The [PushGateway](/client_java/api/io/prometheus/metrics/exporter/pushgateway/PushGateway.html) 
+supports SSL.
 
 ```java
 PushGateway pushGateway = PushGateway.builder()
@@ -109,10 +113,11 @@ PushGateway pushGateway = PushGateway.builder()
 However, this requires that the JVM can validate the server certificate.
 
 If you want to skip certificate verification, you need to provide your own
-[HttpConnectionFactory](/client_java/api/io/prometheus/metrics/exporter/pushgateway/HttpConnectionFactory.html).
+[HttpConnectionFactory](/client_java/api/io/prometheus/metrics/exporter/pushgateway/HttpConnectionFactory.html). <!-- editorconfig-checker-disable-line -->
 The `PushGatewayTestApp` in `integration-tests/it-pushgateway` has a complete example of this.
 
 ## Configuration Properties
 
-The [PushGateway](/client_java/api/io/prometheus/metrics/exporter/pushgateway/PushGateway.html) supports a couple of properties that can be configured at runtime.
+The [PushGateway](/client_java/api/io/prometheus/metrics/exporter/pushgateway/PushGateway.html)
+supports a couple of properties that can be configured at runtime.
 See [config]({{< relref "../config/config.md" >}}).

docs/content/exporters/servlet.md

@@ -4,13 +4,14 @@ weight: 4
 ---
 
 The
-[PrometheusMetricsServlet](/client_java/api/io/prometheus/metrics/exporter/servlet/jakarta/PrometheusMetricsServlet.html)
+[PrometheusMetricsServlet](/client_java/api/io/prometheus/metrics/exporter/servlet/jakarta/PrometheusMetricsServlet.html) <!-- editorconfig-checker-disable-line -->
 is a [Jakarta Servlet](https://jakarta.ee/specifications/servlet/) for exposing a metric endpoint.
 
 ## web.xml
 
 The old-school way of configuring a servlet is in a `web.xml` file:
 
+<!-- editorconfig-checker-disable -->
 ```xml
 <?xml version="1.0" encoding="UTF-8"?>
 <web-app xmlns="https://jakarta.ee/xml/ns/jakartaee"
@@ -27,6 +28,7 @@ The old-school way of configuring a servlet is in a `web.xml` file:
     </servlet-mapping>
 </web-app>
 ```
+<!-- editorconfig-checker-enable -->  
 
 ## Programmatic
 
@@ -36,10 +38,12 @@ The API for that depends on the Servlet container.
 The [examples](https://github.com/prometheus/client_java/tree/1.0.x/examples) directory has an
 example of an embedded
 [Tomcat](https://tomcat.apache.org/) container with the
-[PrometheusMetricsServlet](/client_java/api/io/prometheus/metrics/exporter/servlet/jakarta/PrometheusMetricsServlet.html)
+[PrometheusMetricsServlet](/client_java/api/io/prometheus/metrics/exporter/servlet/jakarta/PrometheusMetricsServlet.html) <!-- editorconfig-checker-disable-line -->
 configured.
 
 ## Spring
 
-You can use the [PrometheusMetricsServlet](/client_java/api/io/prometheus/metrics/exporter/servlet/jakarta/PrometheusMetricsServlet.html) in Spring applications.
+You can use
+the [PrometheusMetricsServlet](/client_java/api/io/prometheus/metrics/exporter/servlet/jakarta/PrometheusMetricsServlet.html) <!-- editorconfig-checker-disable-line -->
+in Spring applications.
 See [our Spring doc]({{< relref "spring.md" >}}).

docs/content/getting-started/labels.md

@@ -80,7 +80,8 @@ loginCount.labelValues(userId, timestamp).inc();
 
 If you register a metric without labels, it will show up immediately with initial value of zero.
 
-However, metrics with labels only show up after the label values are first used. In the example above
+However, metrics with labels only show up after the label values are first used. In the example
+above
 
 ```java
 counter.labelValues("paypal", "error").inc();
@@ -149,4 +150,4 @@ Counter counter = Counter.builder()
 However, most use cases for `constLabels()` are better covered by target labels set by the scraping
 Prometheus server,
 or by one specific metric (e.g. a `build_info` or a `machine_role` metric). See also
-[target labels, not static scraped labels](https://prometheus.io/docs/instrumenting/writing_exporters/#target-labels-not-static-scraped-labels).
+[target labels, not static scraped labels](https://prometheus.io/docs/instrumenting/writing_exporters/#target-labels-not-static-scraped-labels). <!-- editorconfig-checker-disable-line -->

docs/content/getting-started/metric-types.md

@@ -111,7 +111,8 @@ most important options:
 - `classicBuckets(...)`: Set the classic bucket boundaries. Default buckets are `.005`, `.01`,
   `.025`, `.05`, `.1`, `.25`, `.5`, `1`, `2.5`, `5`, `and 10`. The default bucket boundaries are
   designed for measuring request durations in seconds.
-- `nativeMaxNumberOfBuckets()`: Upper limit for the number of native histogram buckets. Default is 160. When the maximum is reached, the native histogram automatically reduces resolution to stay
+- `nativeMaxNumberOfBuckets()`: Upper limit for the number of native histogram buckets. Default is
+  160. When the maximum is reached, the native histogram automatically reduces resolution to stay
   below the limit.
 
 See Javadoc
@@ -198,14 +199,15 @@ be changed with `maxAgeSeconds()` and `numberOfAgeBuckets()`.
 Some options can be configured at runtime, see [config]({{< relref "../config/config.md" >}}).
 
 In general you should prefer histograms over summaries. The Prometheus query language has a
-function [histogram_quantile()](https://prometheus.io/docs/prometheus/latest/querying/functions/#histogram_quantile)
+function [histogram_quantile()](https://prometheus.io/docs/prometheus/latest/querying/functions/#histogram_quantile) <!-- editorconfig-checker-disable-line -->
 for calculating quantiles from histograms. The advantage of query-time quantile calculation is that
 you can aggregate histograms before calculating the quantile. With summaries you must use the
 quantile with all its labels as it is.
 
 ## Info
 
-Info metrics are used to expose textual information which should not change during process lifetime. The value of an Info metric is always `1`.
+Info metrics are used to expose textual information which should not change during process lifetime.
+The value of an Info metric is always `1`.
 
 ```java
 Info info = Info.builder()
@@ -223,11 +225,13 @@ info.setLabelValues(version, vendor, runtime);
 
 The info above looks as follows in OpenMetrics text format:
 
+<!-- editorconfig-checker-disable -->
 ```text
 # TYPE jvm_runtime info
 # HELP jvm_runtime JVM runtime info
 jvm_runtime_info{runtime="OpenJDK Runtime Environment",vendor="Oracle Corporation",version="1.8.0_382-b05"} 1
 ```
+<!-- editorconfig-checker-enable --> 
 
 The example is taken from the `prometheus-metrics-instrumentation-jvm` module, so if you have
 `JvmMetrics` registered you should have a `jvm_runtime_info` metric out-of-the-box.

docs/content/getting-started/multi-target.md

@@ -7,9 +7,11 @@ weight: 7
 This is for the upcoming release 1.1.0.
 {{< /hint >}}
 
-To support multi-target pattern you can create a custom collector overriding the purposed internal method in ExtendedMultiCollector
+To support multi-target pattern you can create a custom collector overriding the purposed internal
+method in ExtendedMultiCollector
 see SampleExtendedMultiCollector in io.prometheus.metrics.examples.httpserver
 
+<!-- editorconfig-checker-disable -->
 ```java
 public class SampleExtendedMultiCollector extends ExtendedMultiCollector {
 
@@ -76,8 +78,11 @@ public class SampleExtendedMultiCollector extends ExtendedMultiCollector {
 }
 
 ```
+<!-- editorconfig-checker-enable --> 
 
-`PrometheusScrapeRequest` provides methods to access http-related infos from the request originally received by the endpoint
+
+`PrometheusScrapeRequest` provides methods to access http-related infos from the request originally
+received by the endpoint
 
 ```java
 public interface PrometheusScrapeRequest {

docs/content/getting-started/performance.md

@@ -53,7 +53,7 @@ In performance critical applications we recommend to use either the classic repr
 native representation, but not both.
 
 You can either configure this in code for each histogram by
-calling [classicOnly()](</client_java/api/io/prometheus/metrics/core/metrics/Histogram.Builder.html#classicOnly()>)
+calling [classicOnly()](</client_java/api/io/prometheus/metrics/core/metrics/Histogram.Builder.html#classicOnly()>) <!-- editorconfig-checker-disable-line -->
 or [nativeOnly()](</client_java/api/io/prometheus/metrics/core/metrics/Histogram.Builder.html#nativeOnly()>),
 or you use the corresponding [config options]({{< relref "../config/config.md" >}}).
 

docs/content/migration/simpleclient.md

@@ -3,23 +3,31 @@ title: Simpleclient
 weight: 1
 ---
 
-The Prometheus Java client library 1.0.0 is a complete rewrite of the underlying data model, and is not backward
+The Prometheus Java client library 1.0.0 is a complete rewrite of the underlying data model, and is
+not backward
 compatible with releases 0.16.0 and older for a variety of reasons:
 
-- The old data model was based on [OpenMetrics](https://openmetrics.io). Native histograms don't fit with the
-  OpenMetrics model because they don't follow the "every sample has exactly one double value" paradigm. It was a lot
-  cleaner to implement a dedicated `prometheus-metrics-model` than trying to fit native histograms into the existing
+- The old data model was based on [OpenMetrics](https://openmetrics.io). Native histograms don't fit
+  with the
+  OpenMetrics model because they don't follow the "every sample has exactly one double value"
+  paradigm. It was a lot
+  cleaner to implement a dedicated `prometheus-metrics-model` than trying to fit native histograms
+  into the existing
   OpenMetrics-based model.
-- Version 0.16.0 and older has multiple Maven modules sharing the same Java package name. This is not supported by the
-  Java module system. To support users of Java modules, we renamed all packages and made sure no package is reused
+- Version 0.16.0 and older has multiple Maven modules sharing the same Java package name. This is
+  not supported by the
+  Java module system. To support users of Java modules, we renamed all packages and made sure no
+  package is reused
   across multiple Maven modules.
 
 ## Migration using the Simpleclient Bridge
 
-Good news: Users of version 0.16.0 and older do not need to refactor all their instrumentation code to get started with
+Good news: Users of version 0.16.0 and older do not need to refactor all their instrumentation code
+to get started with
 1.0.0.
 
-We provide a migration module for bridging the old simpleclient `CollectorRegistry` to the new `PrometheusRegistry`.
+We provide a migration module for bridging the old simpleclient `CollectorRegistry` to the new
+`PrometheusRegistry`.
 
 To use the bridge, add the following dependency:
 
@@ -51,7 +59,8 @@ Then add the following to your code:
 SimpleclientCollector.builder().register();
 ```
 
-This will make all metrics registered with simpleclient's `CollectorRegistry.defaultRegistry` available in the new
+This will make all metrics registered with simpleclient's `CollectorRegistry.defaultRegistry`
+available in the new
 `PrometheusRegistry.defaultRegistry`.
 
 If you are using custom registries, you can specify them like this:
@@ -60,12 +69,15 @@ If you are using custom registries, you can specify them like this:
 CollectorRegistry simpleclientRegistry = ...;
 PrometheusRegistry prometheusRegistry = ...;
 
-SimpleclientCollector.builder().collectorRegistry(simpleclientRegistry).register(prometheusRegistry);
+SimpleclientCollector.builder()
+  .collectorRegistry(simpleclientRegistry)
+  .register(prometheusRegistry);
 ```
 
 ## Refactoring the Instrumentation Code
 
-If you decide to get rid of the old 0.16.0 dependencies and use 1.0.0 only, you need to refactor your code:
+If you decide to get rid of the old 0.16.0 dependencies and use 1.0.0 only, you need to refactor
+your code:
 
 Dependencies:
 
@@ -74,8 +86,10 @@ Dependencies:
 - `simpleclient_httpserver` -> `prometheus-metrics-exporter-httpserver`
 - `simpleclient_servlet_jakarta` -> `prometheus-metrics-exporter-servlet-jakarta`
 
-As long as you are using high-level metric API like `Counter`, `Gauge`, `Histogram`, and `Summary` converting code to
-the new API is relatively straightforward. You will need to adapt the package name and apply some minor changes like
+As long as you are using high-level metric API like `Counter`, `Gauge`, `Histogram`, and `Summary`
+converting code to
+the new API is relatively straightforward. You will need to adapt the package name and apply some
+minor changes like
 using `builder()` instead of `build()` or using `labelValues()` instead of `labels()`.
 
 Example of the old 0.16.0 API:
@@ -106,14 +120,20 @@ Counter counter = Counter.builder()
 counter.labelValues("/hello-world").inc();
 ```
 
-Reasons why we changed the API: Changing the package names was a necessity because the previous package names were
-incompatible with the Java module system. However, renaming packages requires changing code anyway, so we decided to
-clean up some things. For example, the name `builder()` for a builder method is very common in the Java ecosystem, it's
-used in Spring, Lombok, and so on. So naming the method `builder()` makes the Prometheus library more aligned with the
+Reasons why we changed the API: Changing the package names was a necessity because the previous
+package names were
+incompatible with the Java module system. However, renaming packages requires changing code anyway,
+so we decided to
+clean up some things. For example, the name `builder()` for a builder method is very common in the
+Java ecosystem, it's
+used in Spring, Lombok, and so on. So naming the method `builder()` makes the Prometheus library
+more aligned with the
 broader Java ecosystem.
 
-If you are using the low level `Collector` API directly, you should have a look at the new callback metric types,
-see [/getting-started/callbacks/]({{< relref "../getting-started/callbacks.md" >}}). Chances are good that the new callback metrics have
+If you are using the low level `Collector` API directly, you should have a look at the new callback
+metric types,
+see [/getting-started/callbacks/]({{< relref "../getting-started/callbacks.md" >}}). Chances are
+good that the new callback metrics have
 an easier way to achieve what you need than the old 0.16.0 code.
 
 ## JVM Metrics

docs/content/otel/names.md

@@ -5,15 +5,15 @@ weight: 3
 
 OpenTelemetry naming conventions are different from Prometheus naming conventions. The mapping from
 OpenTelemetry metric names to Prometheus metric names is well defined in
-OpenTelemetry's [Prometheus and OpenMetrics Compatibility](https://opentelemetry.io/docs/specs/otel/compatibility/prometheus_and_openmetrics/)
+OpenTelemetry's [Prometheus and OpenMetrics Compatibility](https://opentelemetry.io/docs/specs/otel/compatibility/prometheus_and_openmetrics/) <!-- editorconfig-checker-disable-line -->
 spec, and
-the [OpenTelemetryExporter](/client_java/api/io/prometheus/metrics/exporter/opentelemetry/OpenTelemetryExporter.html)
+the [OpenTelemetryExporter](/client_java/api/io/prometheus/metrics/exporter/opentelemetry/OpenTelemetryExporter.html) <!-- editorconfig-checker-disable-line -->
 implements that specification.
 
 The goal is, if you set up a pipeline as illustrated below, you will see the same metric names in
 the Prometheus server as if you had exposed Prometheus metrics directly.
 
-![Image of a with the Prometheus client library pushing metrics to an OpenTelemetry collector](/client_java/images/otel-pipeline.png)
+![Image of a with the Prometheus client library pushing metrics to an OpenTelemetry collector](/client_java/images/otel-pipeline.png) <!-- editorconfig-checker-disable-line -->
 
 The main steps when converting OpenTelemetry metric names to Prometheus metric names are:
 
@@ -25,7 +25,7 @@ The main steps when converting OpenTelemetry metric names to Prometheus metric n
 
 OpenTelemetry defines not only a line protocol, but also _semantic conventions_, i.e. standardized
 metric and label names. For example,
-OpenTelemetry's [Semantic Conventions for HTTP Metrics](https://opentelemetry.io/docs/specs/otel/metrics/semantic_conventions/http-metrics/)
+OpenTelemetry's [Semantic Conventions for HTTP Metrics](https://opentelemetry.io/docs/specs/otel/metrics/semantic_conventions/http-metrics/) <!-- editorconfig-checker-disable-line -->
 say that if you instrument an HTTP server with OpenTelemetry, you must have a histogram named
 `http.server.duration`.