Update the README and the samples’ build.gradle and pom.xml files to
reflect snapshots now being available from
https://repo.spring.io/snapshot.
Closes#5
Previously, the project provided a Gradle plugin and was only really
intended for use with Gradle. This had influenced a number of design
choices that have proven to be less than ideal when attempting to
use the project with Maven.
This commit backs off from a number of design decisions that worked
well with Gradle but less so with Maven. Part of this is that the
Gradle plugin is (temporarily?) no more. It's been removed in favour
of configuring things directly in build.gradle. While this slightly
increases the amount of configuration required it makes things far
more flexible.
Both samples have been updated with modified Gradle configuration and
new Maven configuration. The README has also been updated to reflect
these changes.
Previously documentation was handled by using a ResultActions
implementation that had custom methods added to it.
Now documentation is handled using a ResultHandler. This has a few
advantages:
- Fit better with the MockMvc programming model. This is similar to
andDo(print())
- Support for using alwaysDo
There's a bug in AsciiDoctor that causes it to handle includes of
absolute paths on Windows incorrectly. This results in the included
document being linked to rather than being included inline in the
document. See [1] for more details.
This commit introduces a work around for the problem. Rather than
using a file path for the includes a URI is now used instead. To
allow the URIs to be read the allow-uri-read attribute is also set.
See [2] for details of the work around.
Closes gh-1
[1] https://github.com/asciidoctor/asciidoctor/issues/1144
[2] http://discuss.asciidoctor.org/Including-a-file-using-an-absolute-path-under-Windows-1-5-0-tp2244p2245.html
Some request mappings that were only intended to handle GET requests
were unconstrained. The commit adds a method = GET constraint to those
mappings to prevent them from handling other HTTP request methods
Previously, the name of an output file was automatically determined
by the name of the method from which the mockMvc.perform call was made.
While (somewhat) clever, to support this for non @Test methods, this
required the use of a CGLib proxy to push and pop some context that
kept track of the name of the current method. This meant it only worked
for non-private methods. It also made it hard to look at the code and
see what would and would not be documented.
This commit updates the library to provide an explicit document method
instead. This method takes the path of an output directory and a
MockMvc ResultActions instance, typically returned from a call to
mockMvc.perform. For example:
document("index",
this.mockMvc.perform(get("/").accept(MediaTypes.HAL_JSON))
.andExpect(status().isOk()));
This will perform a GET request to "/", assert that the response is
200 OK and write documentation snippets for the request and response
to a directory named index.
Previously, whenever a MockMvc perform call was made and the request
and response were to be documented, calls to documentCurlRequest and
documentCurlResponse had to be made.
This commit updates the REST documentation framework to make the
documentation of the request and response automatic. It makes use of
MockMvc’s MockMvcConfigurer that was introduced in Spring 4.1. Applying
RestDocumentationConfiguration once will cause all requests and
responses to be documented:
this.mockMvc = MockMvcBuilders.webAppContextSetup(this.context)
.apply(new RestDocumentationConfiguration()).build();
The path to which the requests and response documentation snippets will
be written is determined by the class and method in which the MockMvc
perform call is made and is currently of the form
shortClassName/methodName(Request|Response|RequestResponse).asciidoc
where shortClassName is the name of the documentation class without its
package. This works for both @Test methods and any non-private methods
that are called from the test method. The methods must be non-private as
a CGLib proxy is used to intercept the calls and configure the output
path.
