AsciidoctorJ 1.6 is not backwards compatible with AsciidoctorJ 1.5
and AsciidoctorJ 2.0 is not backwards compatible with AsciidoctorJ 1.6
or 1.5. The backwards incompatibilities are such that they cannot be
worked around using reflection so code needs to be compiled against
each of the three versions. To this end, this commit splits
spring-restdocs-asciidoctor into several separate modules:
1. spring-restdocs-asciidoctor-support
2. spring-restdocs-asciidoctor-1.5
3. spring-restdocs-asciidoctor-1.6
4. spring-restdocs-asciidoctor-2.0
spring-restdocs-asciidoctor-support contains support code that is not
tied to a specific version of AsciidoctorJ and can be used with
1.5, 1.6 and 2.0. The other three modules contain code that is
specific to a particular version of AsciidoctorJ. Each
version-specific module uses class names that are unique across all
three modules and is written in such a way that they will back off
when used in an environment with a different version of AsciidoctorJ.
The existing spring-restdocs-asciidoctor module has been modified to
merge the version specific jars and the support jar together into a
single jar that supports AsciidoctorJ 1.5, 1.6, and 2.0.
The above-described changes should allow users to depend upon
spring-restdocs-asciidoctor as before and to now be able to use
AsciidoctorJ 1.5, 1.6, or 2.0.
Closes gh-581
Rather than introducing a custom macro, this commit opts to implicitly
configure the snippets attribute instead. The attribute is configured
will the path into which snippets are generated, relative to the
directory that contains the Asciidoctor document that is being
rendered.
The samples and documentation have been updated to use the new
spring-restdocs-asciidoctor module and the implicitly configured
snippets attribute.
Closes gh-297
Rather than requiring an output directory to be explcitly configured,
a default is now automatically configured based on the build tool
that's being used. When using Gradle, snippets will be generated in
build/generated-snippets. When using Maven, snippets will be
generated in target/generated-snippets.
See gh-297
This commit adds a new module, spring-restdocs-restassured, that
can be used to generate documentation snippets when testing a service
with REST Assured.
Please refer to the updated reference documentation for details.
Thanks to Johan Haleby for making a change to REST Assured so that
path parameters could be documented.
Closes gh-102
This commit splits Spring REST Docs into two projects –
spring-restdocs-core and spring-restdocs-mockmvc.
spring-restdocs-core contains the vast majority of the code but does not
depend on a specific test framework other than JUnit. The use of a
Spring Test TestExecutionListener has been replaced with a JUnit test
rule. The rule is declared once per test class and configured with
the output directory to which the generated snippets should be written.
This simplifies the implementation as thread local storage is no longer
required to transfer information about the test that’s running into
Spring REST Docs. Instead, this transfer is now handled by the new test
rule. It has also simplified the configuration as it’s no longer
necessary for users to provide a system property that configures the
output directory.
spring-restdocs-mockmvc contains code that’s specific to using Spring
REST Docs with Spring MVC Test’s MockMvc. This is currently the only
testing framework that’s supported, but it paves the way for adding
support for additional frameworks. REST Assured is one that users seem
particularly interested in (see gh-80 and gh-102).
Closes gh-107
This commit makes extensive changes to the structure of the code. It
introduces a number of separate packages to provide better separation
of the various areas of functionality. Alongside this change the project
has been renamed from spring-restdocs-core to spring-restdocs.
The build has been improved to provide support for building the samples
from the main build using the buildSamples task. While this change has
been made, the samples remain standalone projects so that their
configuration is not dependent on the main project’s build. Running
buildSamples will build the samples using both Maven and Gradle.
All of the main project’s classes now have javadoc and licence/copyright
headers.
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.
