mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-06-27 09:00:04 -04:00
[Dev Docs] Replacing unsupported **Note** with [!Note] (#127102)
* Replacing unsupported **Note** with [!Note]
This commit is contained in:
parent
8dc6bf8893
commit
80946ce385
3 changed files with 15 additions and 21 deletions
29
BUILDING.md
29
BUILDING.md
|
@ -82,7 +82,7 @@ In case of updating a dependency, ensure to remove the unused entry of the outda
|
|||
|
||||
You can also automate the generation of this entry by running your build using the `--write-verification-metadata` commandline option:
|
||||
```
|
||||
>./gradlew --write-verification-metadata sha256 precommit
|
||||
./gradlew --write-verification-metadata sha256 precommit
|
||||
```
|
||||
|
||||
The `--write-verification-metadata` Gradle option is generally able to resolve reachable configurations,
|
||||
|
@ -92,10 +92,10 @@ uses the changed dependencies. In most cases, `precommit` or `check` are good ca
|
|||
We prefer sha256 checksums as md5 and sha1 are not considered safe anymore these days. The generated entry
|
||||
will have the `origin` attribute been set to `Generated by Gradle`.
|
||||
|
||||
>A manual confirmation of the Gradle generated checksums is currently not mandatory.
|
||||
>If you want to add a level of verification you can manually confirm the checksum (e.g. by looking it up on the website of the library)
|
||||
>Please replace the content of the `origin` attribute by `official site` in that case.
|
||||
>
|
||||
> [!Tip]
|
||||
> A manual confirmation of the Gradle generated checksums is currently not mandatory.
|
||||
> If you want to add a level of verification you can manually confirm the checksum (e.g. by looking it up on the website of the library)
|
||||
> Please replace the content of the `origin` attribute by `official site` in that case.
|
||||
|
||||
#### Custom plugin and task implementations
|
||||
|
||||
|
@ -229,13 +229,9 @@ In addition to snapshot builds JitPack supports building Pull Requests. Simply u
|
|||
3. Run the Gradle build as needed. Keep in mind the initial resolution might take a bit longer as this needs to be built
|
||||
by JitPack in the background before we can resolve the adhoc built dependency.
|
||||
|
||||
---
|
||||
|
||||
**NOTE**
|
||||
|
||||
You should only use that approach locally or on a developer branch for production dependencies as we do
|
||||
> [!Note]
|
||||
> You should only use that approach locally or on a developer branch for production dependencies as we do
|
||||
not want to ship unreleased libraries into our releases.
|
||||
---
|
||||
|
||||
#### How to use a custom third party artifact?
|
||||
|
||||
|
@ -265,12 +261,9 @@ allprojects {
|
|||
```
|
||||
4. Run the Gradle build as needed with `--write-verification-metadata` to ensure the Gradle dependency verification does not fail on your custom dependency.
|
||||
|
||||
---
|
||||
**NOTE**
|
||||
|
||||
As Gradle prefers to use modules whose descriptor has been created from real meta-data rather than being generated,
|
||||
> [!Note]
|
||||
> As Gradle prefers to use modules whose descriptor has been created from real meta-data rather than being generated,
|
||||
flat directory repositories cannot be used to override artifacts with real meta-data from other repositories declared in the build.
|
||||
For example, if Gradle finds only `jmxri-1.2.1.jar` in a flat directory repository, but `jmxri-1.2.1.pom` in another repository
|
||||
> For example, if Gradle finds only `jmxri-1.2.1.jar` in a flat directory repository, but `jmxri-1.2.1.pom` in another repository
|
||||
that supports meta-data, it will use the second repository to provide the module.
|
||||
Therefore, it is recommended to declare a version that is not resolvable from public repositories we use (e.g. Maven Central)
|
||||
---
|
||||
> Therefore, it is recommended to declare a version that is not resolvable from public repositories we use (e.g. Maven Central)
|
||||
|
|
|
@ -401,7 +401,8 @@ It is important that the only code covered by the Elastic licence is contained
|
|||
within the top-level `x-pack` directory. The build will fail its pre-commit
|
||||
checks if contributed code does not have the appropriate license headers.
|
||||
|
||||
> **NOTE:** If you have imported the project into IntelliJ IDEA the project will
|
||||
> [!NOTE]
|
||||
> If you have imported the project into IntelliJ IDEA the project will
|
||||
> be automatically configured to add the correct license header to new source
|
||||
> files based on the source location.
|
||||
|
||||
|
|
|
@ -58,8 +58,8 @@ The specification contains:
|
|||
* Request parameters
|
||||
* Request body specification
|
||||
|
||||
**NOTE**
|
||||
If an API is stable but it response should be treated as an arbitrary map of key values please notate this as followed
|
||||
> [!Note]
|
||||
> If an API is stable but it response should be treated as an arbitrary map of key values please notate this as followed
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue