Sync docs from master to gh-pages

This commit is contained in:
buildmaster
2019-01-10 15:47:40 +00:00
parent ba6e9618e6
commit 14ef80851e
4 changed files with 34 additions and 7 deletions

View File

@@ -378,7 +378,7 @@ only supported SCM is Git.</p><p>The repository would have to the following setu
&#9492;&#9472;&#9472; beer-api-consumer
&#9492;&#9472;&#9472; rest
&#9500;&#9472;&#9472; shouldGrantABeerIfOldEnough.json
&#9492;&#9472;&#9472; shouldRejectABeerIfTooYoung.json</pre><p>Under <code class="literal">META-INF</code> folder:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">we group applications via <code class="literal">groupId</code> (e.g. <code class="literal">com.example</code>)</li><li class="listitem">then each application is represented via the <code class="literal">artifactId</code> (e.g. <code class="literal">beer-api-producer-git</code>)</li><li class="listitem">next, the version of the application. The version is mandatory! (e.g. <code class="literal">0.0.1-SNAPSHOT</code>)</li><li class="listitem"><p class="simpara">finally, there are two folders:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "><li class="listitem"><code class="literal">contracts</code> - the good practice is to store the contracts required by each
&#9492;&#9472;&#9472; shouldRejectABeerIfTooYoung.json</pre><p>Under <code class="literal">META-INF</code> folder:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">we group applications via <code class="literal">groupId</code> (e.g. <code class="literal">com.example</code>)</li><li class="listitem">then each application is represented via the <code class="literal">artifactId</code> (e.g. <code class="literal">beer-api-producer-git</code>)</li><li class="listitem"><p class="simpara">next, the version of the application (e.g. <code class="literal">0.0.1-SNAPSHOT</code>). Starting from Spring Cloud Contract version <code class="literal">2.1.0</code>, you can specify the versions as follows (assuming that your versions follow the semantic versioning)</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "><li class="listitem"><p class="simpara"><code class="literal">+</code> or <code class="literal">latest</code> - to find the latest version of your stubs (assuming that the snapshots are always the latest artifact for a given revision number). That means:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: square; "><li class="listitem">if you have a version <code class="literal">1.0.0.RELEASE</code>, <code class="literal">2.0.0.BUILD-SNAPSHOT</code> and <code class="literal">2.0.0.RELEASE</code> we will assume that the latest is <code class="literal">2.0.0.BUILD-SNAPSHOT</code></li><li class="listitem">if you have a version <code class="literal">1.0.0.RELEASE</code> and <code class="literal">2.0.0.RELEASE</code> we will assume that the latest is <code class="literal">2.0.0.RELEASE</code></li><li class="listitem">if you have a version called <code class="literal">latest</code> or <code class="literal">+</code> we will pick that folder</li></ul></div></li><li class="listitem"><p class="simpara"><code class="literal">release</code> - to find the latest release version of your stubs. That means:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: square; "><li class="listitem">if you have a version <code class="literal">1.0.0.RELEASE</code>, <code class="literal">2.0.0.BUILD-SNAPSHOT</code> and <code class="literal">2.0.0.RELEASE</code> we will assume that the latest is <code class="literal">2.0.0.RELEASE</code></li><li class="listitem">if you have a version called <code class="literal">release</code> we will pick that folder</li></ul></div></li></ul></div></li><li class="listitem"><p class="simpara">finally, there are two folders:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "><li class="listitem"><code class="literal">contracts</code> - the good practice is to store the contracts required by each
consumer in the folder with the consumer name (e.g. <code class="literal">beer-api-consumer</code>). That way you
can use the <code class="literal">stubs-per-consumer</code> feature. Further directory structure is arbitrary.</li><li class="listitem"><code class="literal">mappings</code> - in this folder the Maven / Gradle Spring Cloud Contract plugins will push
the stub server mappings. On the consumer side, Stub Runner will scan this folder