undo some changes with the css fix

platforms/documentation/docs/src/docs/userguide/api/kotlin_dsl.adoc

@@ -220,9 +220,12 @@ The Kotlin DSL currently supports type-safe model accessors for any of the follo
 * Elements in <<kotdsl:containers,project-extension containers>> (for example the source sets contributed by the Java Plugin that are added to the `sourceSets` container)
 * Extensions on each of the above
 
-IMPORTANT: Only the main project build scripts and precompiled project script plugins have type-safe model accessors.
+[IMPORTANT]
+====
+Only the main project build scripts and precompiled project script plugins have type-safe model accessors.
 Initialization scripts, settings scripts, script plugins do not.
 These limitations will be removed in a future Gradle release.
+====
 
 The set of type-safe model accessors available is calculated right before evaluating the script body, immediately after the `plugins {}` block.
 Any model elements contributed after that point do not work with type-safe model accessors.
@@ -568,7 +571,11 @@ include::sample[dir="snippets/kotlinDsl/containers-delegated-properties/kotlin",
 <1> Uses the reference to the `myTask1` task rather than a task path
 
 
-NOTE: The above rely on configuration avoidance APIs. If you need to eagerly configure or register container elements simply replace link:{kotlinDslPath}/gradle/org.gradle.kotlin.dsl/existing.html[`existing()`] with link:{kotlinDslPath}/gradle/org.gradle.kotlin.dsl/getting.html[`getting()`] and link:{kotlinDslPath}/gradle/org.gradle.kotlin.dsl/registering.html[`registering()`] with link:{kotlinDslPath}/gradle/org.gradle.kotlin.dsl/creating.html[`creating()`].
+[NOTE]
+====
+The above rely on configuration avoidance APIs.
+If you need to eagerly configure or register container elements simply replace link:{kotlinDslPath}/gradle/org.gradle.kotlin.dsl/existing.html[`existing()`] with link:{kotlinDslPath}/gradle/org.gradle.kotlin.dsl/getting.html[`getting()`] and link:{kotlinDslPath}/gradle/org.gradle.kotlin.dsl/registering.html[`registering()`] with link:{kotlinDslPath}/gradle/org.gradle.kotlin.dsl/creating.html[`creating()`].
+====
 
 === Configuring multiple container elements together
 

platforms/documentation/docs/src/docs/userguide/authoring-builds/best-practices/organizing_gradle_projects.adoc

@@ -214,9 +214,9 @@ Optionally, the `buildSrc` directory can host a build script if additional confi
 [NOTE]
 ====
 A change in `buildSrc` causes the whole project to become out-of-date.
-Thus, when making small incremental changes, the <<command_line_interface#sec:command_line_execution_options, `--no-rebuild` command-line option>> is often helpful to get faster feedback.
 
-Remember to run a full build regularly or at least when you're done, though.
+Thus, when making small incremental changes, the <<command_line_interface#sec:command_line_execution_options, `--no-rebuild` command-line option>> is often helpful to get faster feedback.
+Remember to run a full build regularly.
 ====
 
 == Declare properties in `gradle.properties` file

platforms/documentation/docs/src/docs/userguide/authoring-builds/other/init_scripts.adoc

@@ -68,7 +68,6 @@ Each init script also implements the link:{groovyDslPath}/org.gradle.api.Script.
 [NOTE]
 ====
 When writing init scripts, pay attention to the scope of the reference you are trying to access.
-
 For example, properties loaded from `gradle.properties` are available on `Settings` or `Project` instances but not on the `Gradle` one.
 ====
 

platforms/documentation/docs/src/docs/userguide/authoring-builds/other/test_kit.adoc

@@ -83,7 +83,6 @@ The GradleRunner uses the <<third_party_integration.adoc#embedding,Tooling API>>
 [NOTE]
 ====
 GradleRunner supports the same range of Gradle versions as the Tooling API.
-
 The supported versions are defined in the <<third_party_integration.adoc#sec:embedding_compatibility,compatibility matrix>>.
 
 Builds with older Gradle versions _may_ still work but there are no guarantees.

platforms/documentation/docs/src/docs/userguide/authoring-builds/other/working_with_files.adoc

@@ -173,8 +173,11 @@ include::sample[dir="snippets/files/archives/groovy",files="build.gradle[tags=un
 <2> Remaps the path of the extracting files into the destination directory by dropping the `libs` segment from the file path
 <3> Ignores the empty directories resulting from the remapping, see Caution note below
 
-CAUTION: You can not change the destination path of empty directories with this technique.
+[CAUTION]
+====
+You can not change the destination path of empty directories with this technique.
 You can learn more in https://github.com/gradle/gradle/issues/2940[this issue].
+====
 
 If you're a Java developer and are wondering why there is no `jarTree()` method, that's because `zipTree()` works perfectly well for JARs, WARs and EARs.
 
@@ -302,7 +305,12 @@ In addition, this example could be improved further by relying on the Java plugi
 Gradle provides the link:{groovyDslPath}/org.gradle.api.Project.html#org.gradle.api.Project:file(java.lang.Object)[Project.file(java.lang.Object)] method for specifying the location of a single file or directory.
 Relative paths are resolved relative to the project directory, while absolute paths remain unchanged.
 
-CAUTION: Never use `new File(relative path)` unless passed to `file()` or `files()` or `from()` or other methods being defined in terms of `file()` or `files()`. Otherwise this creates a path relative to the current working directory (CWD). Gradle can make no guarantees about the location of the CWD, which means builds that rely on it may break at any time.
+[CAUTION]
+====
+Never use `new File(relative path)` unless passed to `file()` or `files()` or `from()` or other methods being defined in terms of `file()` or `files()`.
+Otherwise this creates a path relative to the current working directory (CWD).
+Gradle can make no guarantees about the location of the CWD, which means builds that rely on it may break at any time.
+====
 
 Here are some examples of using the `file()` method with different types of argument:
 
@@ -708,7 +716,12 @@ Notice how the `src/dist` configuration has a nested inclusion specification: th
 
 The above example also demonstrates how you can copy files into a subdirectory of the destination either by using a child `into()` on a `from()` or a child `from()` on an `into()`. Both approaches are acceptable, but you may want to create and follow a convention to ensure consistency across your build files.
 
-NOTE: Don't get your `into()` specifications mixed up! For a normal copy — one to the filesystem rather than an archive — there should always be _one_ "root" `into()` that simply specifies the overall destination directory of the copy. Any other `into()` should have a child spec attached and its path will be relative to the root `into()`.
+[NOTE]
+====
+Don't get your `into()` specifications mixed up! ]
+For a normal copy — one to the filesystem rather than an archive — there should always be _one_ "root" `into()` that simply specifies the overall destination directory of the copy.
+Any other `into()` should have a child spec attached and its path will be relative to the root `into()`.
+====
 
 One final thing to be aware of is that a child copy spec inherits its destination path, include patterns, exclude patterns, copy actions, name mappings and filters from its parent. So be careful where you place your configuration.
 

platforms/documentation/docs/src/docs/userguide/authoring-builds/structuring/composite_builds.adoc

@@ -108,7 +108,6 @@ include::sample[dir="snippets/developingPlugins/testingPlugins/groovy/include-pl
 [NOTE]
 ====
 You may also use the `includeBuild` mechanism outside `pluginManagement` to include plugin builds.
-
 However, this does not support all use cases and including plugin builds like that might be deprecated in a future Gradle version.
 ====
 
@@ -127,7 +126,6 @@ Every included build:
 [NOTE]
 ====
 When a composite build is included into another composite build, then both included builds would have the same parent.
-
 In other words, nested composite build structure is flattened.
 ====
 

platforms/documentation/docs/src/docs/userguide/authoring-builds/structuring/structuring_software_products_details.adoc

@@ -74,7 +74,6 @@ It might also speed up the IDE performance in the case of a very large code base
 [NOTE]
 ====
 If all components live in the same repository, you should only have one <<gradle_wrapper.adoc#sec:adding_wrapper,Gradle wrapper>> in the root of the repository.
-
 If you have an umbrella build there, you can use that to manage the wrapper.
 ====
 

platforms/documentation/docs/src/docs/userguide/authoring-builds/tasks/custom_tasks.adoc

@@ -483,7 +483,12 @@ If any failures occur while executing the asynchronous work, the task will fail
 
 In some cases, however, it might be desirable to wait for work to complete before exiting the task action. This is possible using the link:{javadocPath}/org/gradle/workers/WorkQueue.html#await--[WorkQueue.await()] method. As in the case of allowing the work to complete asynchronously, any failures that occur while executing an item of work will be surfaced as a link:{javadocPath}/org/gradle/workers/WorkerExecutionException.html[WorkerExecutionException] thrown from the link:{javadocPath}/org/gradle/workers/WorkQueue.html#await--[WorkQueue.await()] method.
 
-NOTE: Note that Gradle will only begin running other independent tasks in parallel when a task has exited a task action and returned control of execution to Gradle. When link:{javadocPath}/org/gradle/workers/WorkQueue.html#await--[WorkQueue.await()] is used, execution does not leave the task action. This means that Gradle will not allow other tasks to begin executing and will wait for the task action to complete before doing so.
+[NOTE]
+====
+Note that Gradle will only begin running other independent tasks in parallel when a task has exited a task action and returned control of execution to Gradle.
+When link:{javadocPath}/org/gradle/workers/WorkQueue.html#await--[WorkQueue.await()] is used, execution does not leave the task action.
+This means that Gradle will not allow other tasks to begin executing and will wait for the task action to complete before doing so.
+====
 
 .Waiting for asynchronous work to complete
 ====

platforms/documentation/docs/src/docs/userguide/authoring-builds/tasks/more_about_tasks.adoc

@@ -78,9 +78,13 @@ include::sample[dir="snippets/tasks/defineAsKotlinDelegatedProperty/kotlin",file
 include::sample[dir="snippets/tasks/defineAsKotlinDelegatedProperty/groovy",files="build.gradle[]"]
 ====
 
-WARNING: If you look at the API of the _tasks_ container you may notice that there are additional methods to _create_ tasks.
-The use of these methods is discouraged and will be deprecated in future versions.
+[WARNING]
+====
+If you look at the API of the _tasks_ container you may notice that there are additional methods to _create_ tasks.
+*The use of these methods is discouraged* and will be deprecated in future versions.
+
 These methods only exist for backward compatibility as they were introduced before <<task_configuration_avoidance#task_configuration_avoidance,task configuration avoidance>> was added to Gradle.
+====
 
 [[sec:locating_tasks]]
 == Locating tasks
@@ -166,7 +170,6 @@ Have a look at link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html[TaskCo
 [TIP]
 ====
 If you use the _Kotlin DSL_ and the task you want to configure was added by a plugin, you can use a convenient accessor for the task.
-
 That is, instead of `tasks.named("test")` you can just write `tasks.test`.
 ====
 

platforms/documentation/docs/src/docs/userguide/authoring-builds/tasks/task_configuration_avoidance.adoc

@@ -63,7 +63,12 @@ In the event you still need to get access to a Task instance, you can use link:{
 [[sec:how_do_i_order_tasks]]
 === How do I order tasks with configuration avoidance in mind?
 
-NOTE: Calling ordering methods will not cause task creation by itself. All these methods do is declare relationships. However, it's important to note, that the existence of these relationships might indirectly cause task creation in later stages of the build process.
+[NOTE]
+====
+Calling ordering methods will not cause task creation by itself.
+All these methods do is declare relationships.
+However, it's important to note, that the existence of these relationships might indirectly cause task creation in later stages of the build process.
+====
 
 When task relationships need to be established (i.e. `dependsOn`, `finalizedBy`, `mustRunAfter`, `shouldRunAfter`), a distinction can be made between soft, and strong relationships, as their effects on task creation in configuration time differ:
 

platforms/documentation/docs/src/docs/userguide/core-plugins/idea_plugin.adoc

@@ -19,7 +19,11 @@ WARNING: The IDEA Plugin is not compatible with the <<configuration_cache.adoc#c
 
 The IDEA plugin generates files that are used by http://www.jetbrains.com/idea/[IntelliJ IDEA], thus making it possible to open the project from IDEA (`File` - `Open Project`). Both external dependencies (including associated source and Javadoc files) and project dependencies are considered.
 
-NOTE: If you simply want to load a Gradle project into IntelliJ IDEA, then use the IDE's https://www.jetbrains.com/help/idea/gradle.html#gradle_import[import facility]. You do not need to apply this plugin to import your project into IDEA, although if you do, the import will take account of any extra IDEA configuration you have that doesn't directly modify the generated files — see the <<#sec:idea_configuration,Configuration>> section for more details.
+[NOTE]
+====
+If you simply want to load a Gradle project into IntelliJ IDEA, then use the IDE's https://www.jetbrains.com/help/idea/gradle.html#gradle_import[import facility].
+You do not need to apply this plugin to import your project into IDEA, although if you do, the import will take account of any extra IDEA configuration you have that doesn't directly modify the generated files — see the <<#sec:idea_configuration,Configuration>> section for more details.
+====
 
 What exactly the IDEA plugin generates depends on which other plugins are used:
 

platforms/documentation/docs/src/docs/userguide/core-plugins/jacoco_plugin.adoc

@@ -104,8 +104,11 @@ include::sample[dir="snippets/testing/jacoco-quickstart/kotlin",files="build.gra
 include::sample[dir="snippets/testing/jacoco-quickstart/groovy",files="build.gradle[tags=testtask-configuration]"]
 ====
 
-NOTE: Tasks configured for running with the JaCoCo agent delete the destination file for the execution data when the task starts executing.
+[NOTE]
+====
+Tasks configured for running with the JaCoCo agent delete the destination file for the execution data when the task starts executing.
 This ensures that no stale coverage data is present in the execution data.
+====
 
 === Default values of the JaCoCo Task extension
 

platforms/documentation/docs/src/docs/userguide/core-plugins/play_plugin.adoc

@@ -15,5 +15,8 @@
 [[play_plugin]]
 = Building Play applications
 
-CAUTION: Play web application support was deprecated in Gradle 5 and replaced by an external Play plugin in Gradle 6.
+[CAUTION]
+====
+Play web application support was deprecated in Gradle 5 and replaced by an external Play plugin in Gradle 6.
 Please use the new https://gradle.github.io/playframework[Gradle Play Plugin], available from the plugin portal, instead.
+====

platforms/documentation/docs/src/docs/userguide/core-plugins/pmd_plugin.adoc

@@ -87,7 +87,10 @@ include::sample[dir="snippets/codeQuality/codeQuality/kotlin",files="build.gradl
 include::sample[dir="snippets/codeQuality/codeQuality/groovy",files="build.gradle[tags=pmd-threads]"]
 ====
 
-NOTE: This configuration is internal to PMD and is not linked to <<performance#parallel_execution,the number of workers>> used by Gradle.
+[NOTE]
+====
+This configuration is internal to PMD and is not linked to <<performance#parallel_execution,the number of workers>> used by Gradle.
 It means that you have to pay attention to the value entered here and make sure it still makes sense in a multi project build.
 This is because parallel Gradle task execution could result in different PMD tasks from different projects running in parallel.
 If multiple PMD tasks execute simultaneously in n projects, then up to a maximum of (n * `thread`) PMD threads could run at the same time.
+====

platforms/documentation/docs/src/docs/userguide/dep-man/01-core-dependency-management/declaring_dependencies.adoc

@@ -192,9 +192,12 @@ See the link:{groovyDslPath}/org.gradle.api.artifacts.dsl.DependencyHandler.html
 
 Gradle provides different notations for module dependencies. There is a string notation and a map notation. A module dependency has an API which allows further configuration. Have a look at link:{javadocPath}/org/gradle/api/artifacts/ExternalModuleDependency.html[ExternalModuleDependency] to learn all about the API. This API provides properties and configuration methods. Via the string notation you can define a subset of the properties. With the map notation you can define all properties. To have access to the complete API, either with the map or with the string notation, you can assign a single dependency to a configuration together with a closure.
 
-NOTE: If you declare a module dependency, Gradle looks for a module metadata file (`.module`, `.pom` or `ivy.xml`) in the repositories.
+[NOTE]
+====
+If you declare a module dependency, Gradle looks for a module metadata file (`.module`, `.pom` or `ivy.xml`) in the repositories.
 If such a module metadata file exists, it is parsed and the artifacts of this module (e.g. `hibernate-3.0.5.jar`) as well as its dependencies (e.g. `cglib`) are downloaded.
 If no such module metadata file exists, as of Gradle 6.0, you need to configure <<declaring_repositories.adoc#sec:supported_metadata_sources,metadata sources definitions>> to look for an artifact file called `hibernate-3.0.5.jar` directly.
+====
 
 [IMPORTANT]
 ====
@@ -229,9 +232,12 @@ link:{javadocPath}/org/gradle/api/file/ProjectLayout.html#files-java.lang.Object
 and link:{groovyDslPath}/org.gradle.api.Project.html#org.gradle.api.Project:fileTree(java.lang.Object)[Project.fileTree(java.lang.Object)]
 Alternatively, you can also define the source directory of one or many file dependencies in the form of a <<declaring_repositories.adoc#sub:flat_dir_resolver,flat directory repository>>.
 
-NOTE: The order of the files in a `FileTree` is not stable, even on a single computer.
+[NOTE]
+====
+The order of the files in a `FileTree` is not stable, even on a single computer.
 It means that dependency configuration seeded with such a construct may produce a resolution result which has a different ordering, possibly impacting the cacheability of tasks using the result as an input.
 Using the simpler `files` instead is recommended where possible.
+====
 
 File dependencies allow you to directly add a set of files to a configuration, without first adding them to a repository. This can be useful if you cannot, or do not want to, place certain files in a repository. Or if you do not want to use any repositories at all for storing your dependencies.
 
@@ -247,10 +253,6 @@ File dependencies are not included in the published dependency descriptor for yo
 However, file dependencies are included in transitive project dependencies within the same build.
 This means they cannot be used outside the current build, but they can be used within the same build.
 
-NOTE: The order of the files in a `FileTree` is not stable, even on a single computer.
-It means that dependency configuration seeded with such a construct may produce a resolution result which has a different ordering, possibly impacting the cacheability of tasks using the result as an input.
-Using the simpler `files` instead is recommended where possible.
-
 You can declare which tasks produce the files for a file dependency.
 You might do this when, for example, the files are generated by the build.