Fix formatting problems in the documentation
Previously, the included .adoc files did not consistently end with a blank line. In certain cases, Asciidoctor requires a blank line before a new section. As a result, the lack of blank lines meant that some section headings did not appear correctly. This commit updates each of the included .adoc files in the documentation to ensure that each ends with a blank line.
This commit is contained in:
@@ -113,4 +113,4 @@ include::{examples-dir}/com/example/mockmvc/CustomDefaultSnippets.java[tags=cust
|
||||
.REST Assured
|
||||
----
|
||||
include::{examples-dir}/com/example/restassured/CustomDefaultSnippets.java[tags=custom-default-snippets]
|
||||
----
|
||||
----
|
||||
|
||||
@@ -33,4 +33,4 @@ welcome. The source code is on {github}[GitHub]. You may want to search the
|
||||
{github}/issues?q=is%3Aissue[existing issues] and {github}/pulls?q=is%3Apr[pull requests]
|
||||
to see if the enhancement is already being worked on. You may also want to
|
||||
{github}/issues/new[open a new issue] to discuss a possible enhancement before work on it
|
||||
begins.
|
||||
begins.
|
||||
|
||||
@@ -148,4 +148,4 @@ preprocessor in exactly the same way as any of the built-in preprocessors.
|
||||
|
||||
If you only want to modify the content (body) of a request or response, consider
|
||||
implementing the `ContentModifier` interface and using it with the built-in
|
||||
`ContentModifyingOperationPreprocessor`.
|
||||
`ContentModifyingOperationPreprocessor`.
|
||||
|
||||
@@ -1198,4 +1198,4 @@ and adds a title:
|
||||
----
|
||||
<1> Add a title to the table
|
||||
<2> Add a new column named "Constraints"
|
||||
<3> Include the descriptors' `constraints` attribute in each row of the table
|
||||
<3> Include the descriptors' `constraints` attribute in each row of the table
|
||||
|
||||
@@ -22,4 +22,4 @@ and the HTTP responses that it produces. Spring REST Docs allows you to work wit
|
||||
resources and the HTTP requests and responses, shielding your documentation
|
||||
from the inner-details of your service's implementation. This separation helps you to
|
||||
document your service's API rather than its implementation. It also frees you to evolve
|
||||
the implementation without having to rework the documentation.
|
||||
the implementation without having to rework the documentation.
|
||||
|
||||
@@ -174,4 +174,4 @@ in a cell that contains the value of a `description` attribute:
|
||||
==== Further reading
|
||||
|
||||
Refer to the http://asciidoctor.org/docs/user-manual/#tables[Tables section of
|
||||
the Asciidoctor user manual] for more information about customizing tables.
|
||||
the Asciidoctor user manual] for more information about customizing tables.
|
||||
|
||||
@@ -25,4 +25,4 @@ format].
|
||||
Markdown has no built-in support for including one Markdown file in another. To include
|
||||
the generated snippets of Markdown in your documentation, you should use an additional
|
||||
tool that supports this functionality. One example that's particularly well-suited to
|
||||
documenting APIs is https://github.com/tripit/slate[Slate].
|
||||
documenting APIs is https://github.com/tripit/slate[Slate].
|
||||
|
||||
Reference in New Issue
Block a user