lsm/initializr
1
0
Fork 0
mirror of https://gitee.com/dcren/initializr.git synced 2025-04-05 17:38:06 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Polish

Browse Source
This commit is contained in:
Dave Syer 2017-04-15 07:17:37 +01:00 committed by Stephane Nicoll
parent be901fec76
commit 8bfa36c44f
3 changed files with 86 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
initializr-docs/src/main/asciidoc/configuration-guide.adoc
View File

@ -478,7 +478,10 @@ recommended) description. In the web UI the links are not currently rendered.
==== Improve search results
Each dependency can have a "weight" (a number >=0) and also "keywords" (list of string)
that are used to prioritize them in the search feature in the UI. If you type one of the keywords into the "Dependencies" box in the UI, those dependencies will be listed below, in order of decreasing weight, if they have one (unweighted dependencies come last).
that are used to prioritize them in the search feature in the web UI. If you type one of
the keywords into the "Dependencies" box in the UI, those dependencies will be listed
below, in order of decreasing weight, if they have one (unweighted dependencies come
last).
[[configuration-howto]]
@ -631,7 +634,7 @@ is a dependency with the web facet).
A dependency group is a hint for user interface implememtations, to group things together
for users when they are selecting dependencies. It is also a convenient way to share
settings between dependencies because every dependency inherits all the settings. Th emost
settings between dependencies because every dependency inherits all the settings. The most
common settings in a group are the group id, version range (for Spring Boot versions), and
bom. Example:
@ -644,10 +647,10 @@ initializr:
versionRange: "[1.3.0.RELEASE,2.0.x)"
content:
...
---
----
These dependencies, by default, will be available only for Spring Boot versions 1.3 to
2.0, and will bring in a BOM declared as "stuff-bom" in the `env` section.
2.0, and will bring in a BOM already declared as "stuff-bom" in the `env` section.
[[create-instance-advanced-config]]
== Advanced configuration

6
initializr-docs/src/main/asciidoc/metadata-format.adoc
View File

@ -4,7 +4,7 @@ This section describes the hal/json structure of the metadata exposed by the
initializr. Such metadata can be used by third party clients to provide a list of
options and default settings that can be used to request the creation of a project.
Each third-party client is advised to set a `User-Agent` header for *each* request
A third-party client is advised to set a `User-Agent` header for *each* request
sent to the service. A good structure for a user agent is `clientId/clientVersion`
(i.e. `foo/1.2.0` for the "foo" client and version `1.2.0`).
@ -72,8 +72,8 @@ attribute of each type gives you the root action to invoke on the server. This
requires more manual handling on your end.
=== Project dependencies
A dependency is usually the coordinates of a _starter_ module but it can be just as
well be a regular dependency. A typical dependency structure looks like this:
A dependency is usually the coordinates of a _starter_ module but it can be just a regular
dependency. A typical dependency structure looks like this:
```json
{

88
initializr-docs/src/main/asciidoc/using-the-stubs.adoc
View File

@ -15,6 +15,8 @@ of your client.
== Using WireMock with Spring Boot
=== Loading Stubs from the Classpath
A convenient way to consume the stubs in your project is to add a test dependency:
[source,xml,indent=0,subs="attributes,specialchars"]
@ -48,9 +50,62 @@ public class ClientApplicationTests {
}
----
Alternatively you can configure the stub runner to look for the artifact. The example
below will automatically download, if necessary, the latest version of the initializr
stubs:
The wiremock fetaures come with Spring Cloud Contract Wiremock:
[source,xml,indent=0,subs="attributes,specialchars"]
----
<dependencies>
...
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-contract-wiremock</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-dependencies</artifactId>
<version>1.0.3.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
---
=== Using the Stub Runner
Alternatively you can configure the stub runner to look for the artifact, using a
different Spring Cloud Contract dependency:
`spring-cloud-starter-contract-stub-runner`. The example below will automatically
download, if necessary, the latest version of the initializr stubs (so you don't need the
stubs declared as a dependency):
[source,xml,indent=0,subs="attributes,specialchars"]
----
<dependencies>
...
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-contract-stubrunner</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-dependencies</artifactId>
<version>1.0.3.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
---
[source,java,indent=0]
----
@ -80,12 +135,21 @@ Then you have a server that returns the stub of the JSON metadata
== Names and Paths of Stubs
The stubs are laid out in a jar file in a form (under "/mappings") that can be
consumed by WireMock just by setting its file source. The names of the individual
stubs are the same as the method names of the test cases that generated them in the
Initializr project. So for example there is a test case "metadataWithV2AcceptHeader"
in `MainControllerIntegrationTests` that makes assertions about the response when the
accept header is `application/vnd.initializr.v2.1+json`. The response is recorded in
the stub, and it will match in WireMock if the same headers and request parameters
that were used in the Initializr test case and used in the client. The method name
usually summarizes what those values are.
The stubs are laid out in a jar file in a form (under "**/mappings") that can be consumed
by WireMock just by setting its file source. The names of the individual stubs are the
same as the method names of the test cases that generated them in the Initializr
project. So for example there is a test case "metadataWithV2AcceptHeader" in
`MainControllerIntegrationTests` that makes assertions about the response when the accept
header is `application/vnd.initializr.v2.1+json`. The response is recorded in the stub,
and it will match in WireMock if the same headers and request parameters that were used in
the Initializr test case and used in the client. The method name usually summarizes what
those values are.
The stub runner, and the `@AutoConfigureWireMock` in the examples above loads all the
stubs into WireMock, so you don't necessarily need to know the names of the stubs. You can
also register stubs one by one, though, in which case it would help to scan the stubs jar
and compare the file names with the test methods. For instance, if you look in the stubs
jar, you will see a file called `metadataWithV2AcceptHeader.json` and, in the
initializr-web project, a test method called `metadataWithV2AcceptHeader` which generated
it.