spring-cloud__spring-cloud-config_CVE-2020-5405_2-1-6-RELEASE

//// DIESE DATEI NICHT BEARBEITEN. SIE WURDE GENERIERT. Manuelle Änderungen an dieser Datei gehen verloren, wenn sie erneut generiert wird. Bearbeiten Sie stattdessen die Dateien im Verzeichnis src/main/asciidoc/. ////

image::https://circleci.com/gh/spring-cloud/spring-cloud-config/tree/master.svg?style=svg["CircleCI", link="https://circleci.com/gh/spring-cloud/spring-cloud-config/tree/master"] image::https://codecov.io/gh/spring-cloud/spring-cloud-config/branch/master/graph/badge.svg["Codecov", link="https://codecov.io/gh/spring-cloud/spring-cloud-config/branch/master"] image::https://api.codacy.com/project/badge/Grade/f064024a072c477e97dca6ed5a70fccd?branch=master["Codacy code quality", link="https://www.codacy.com/app/Spring-Cloud/spring-cloud-config?branch=master&utm_source=github.com&utm_medium=referral&utm_content=spring-cloud/spring-cloud-config&utm_campaign=Badge_Grade"]

Spring Cloud Config bietet serverseitige und clientseitige Unterstützung für externalisierte Konfiguration in einem verteilten System. Mit dem Config Server haben Sie einen zentralen Ort, um externe Eigenschaften für Anwendungen über alle Umgebungen hinweg zu verwalten. Die Konzepte auf Client- und Serverseite bilden sich identisch auf die Spring-Environment- und PropertySource-Abstraktionen ab, passen also sehr gut zu Spring-Anwendungen, können aber mit jeder Anwendung verwendet werden, die in einer beliebigen Sprache läuft. Wenn eine Anwendung die Deployment-Pipeline von der Entwicklung über den Test bis zur Produktion durchläuft, können Sie die Konfiguration zwischen diesen Umgebungen verwalten und sicher sein, dass die Anwendungen alles haben, was sie zum Ausführen benötigen, wenn sie migrieren. Die Standardimplementierung des serverseitigen Speicher-Backends verwendet Git und unterstützt daher problemlos gelabelte Versionen von Konfigurationsumgebungen und ist zudem für eine breite Palette von Werkzeugen zur Verwaltung des Inhalts zugänglich. Alternative Implementierungen lassen sich einfach hinzufügen und über die Spring-Konfiguration einbinden.

== Funktionen

=== Spring Cloud Config Server

Spring Cloud Config Server bietet die folgenden Vorteile:

• HTTP-API auf Ressourcenbasis für externe Konfiguration (Name-Wert-Paare oder entsprechender YAML-Inhalt)
• Eigenschaftswerte verschlüsseln und entschlüsseln (symmetrisch oder asymmetrisch)
• Leicht in eine Spring-Boot-Anwendung einbettbar mit @EnableConfigServer

=== Spring Cloud Config Client

Speziell für Spring-Anwendungen ermöglicht der Spring Cloud Config Client Folgendes:

• An den Config Server binden und die Spring-Environment mit Remote-Property-Quellen initialisieren.
• Eigenschaftswerte verschlüsseln und entschlüsseln (symmetrisch oder asymmetrisch).
• @RefreshScope für Spring-@Beans, die bei Konfigurationsänderungen neu initialisiert werden sollen.
• Verwaltungs-Endpunkte verwenden: ** /env zum Aktualisieren der Environment und Neubinden von @ConfigurationProperties und Log-Leveln. ** /refresh zum Aktualisieren der @RefreshScope-Beans. ** /restart zum Neustarten des Spring-Kontexts (standardmäßig deaktiviert). ** /pause und /resume zum Aufrufen der Lifecycle-Methoden (stop() und auf dem ).

== Schnellstart

Dieser Schnellstart führt durch die Verwendung von Server und Client von Spring Cloud Config Server.

Starten Sie zuerst den Server wie folgt:

$ cd spring-cloud-config-server $ ../mvnw spring-boot:run

Der Server ist eine Spring-Boot-Anwendung, sodass Sie ihn bei Bedarf auch aus Ihrer IDE heraus ausführen können (die Hauptklasse ist ConfigServerApplication).

Testen Sie als Nächstes einen Client wie folgt:

$ curl localhost:8888/foo/development {"name":"foo","label":"master","propertySources":[ {"name":"https://github.com/scratches/config-repo/foo-development.properties","source":{"bar":"spam"}}, {"name":"https://github.com/scratches/config-repo/foo.properties","source":{"foo":"bar"}} ]}

Die Standardstrategie zum Auffinden von Property-Quellen besteht darin, ein Git-Repository (unter spring.cloud.config.server.git.uri) zu klonen und es zur Initialisierung einer Mini-SpringApplication zu verwenden. Die Environment der Mini-Anwendung wird verwendet, um Property-Quellen aufzulisten und über einen JSON-Endpunkt zu veröffentlichen.

Der HTTP-Dienst stellt Ressourcen in der folgenden Form bereit:

/{application}/{profile}[/{label}] /{application}-{profile}.yml /{label}/{application}-{profile}.yml /{application}-{profile}.properties /{label}/{application}-{profile}.properties

wobei application als spring.config.name in die SpringApplication injiziert wird (was in einer normalen Spring-Boot-App normalerweise application ist), profile ein aktives Profil ist (oder eine durch Kommas getrennte Liste von Eigenschaften) und label ein optionales Git-Label ist (Standardwert: master.)

Spring Cloud Config Server bezieht Konfiguration für Remote-Clients aus verschiedenen Quellen. Das folgende Beispiel bezieht die Konfiguration aus einem Git-Repository (das bereitgestellt werden muss), wie im folgenden Beispiel gezeigt:

[source,yaml]

spring: cloud: config: server: git: uri: https://github.com/spring-cloud-samples/config-repo

Weitere mögliche Quellen sind JDBC-kompatible Datenbanken, Subversion, Hashicorp Vault, Credhub und lokale Dateisysteme.

=== Clientseitige Verwendung

Um diese Funktionen in einer Anwendung zu nutzen, können Sie sie als Spring-Boot-Anwendung erstellen, die von spring-cloud-config-client abhängt (ein Beispiel finden Sie in den Testfällen für den Config-Client oder in der Beispielanwendung). Der bequemste Weg, die Abhängigkeit hinzuzufügen, ist ein Spring-Boot-Starter org.springframework.cloud:spring-cloud-starter-config. Es gibt außerdem ein Parent-POM und eine BOM (spring-cloud-starter-parent) für Maven-Benutzer sowie eine Properties-Datei für die Spring-IO-Versionsverwaltung für Gradle- und Spring-CLI-Benutzer. Das folgende Beispiel zeigt eine typische Maven-Konfiguration:

[source,xml,indent=0] .pom.xml

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>{spring-boot-docs-version}</version>
    <relativePath /> <!-- lookup parent from repository -->
</parent>

<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-dependencies</artifactId>
			<version>{spring-cloud-version}</version>
			<type>pom</type>
			<scope>import</scope>
		</dependency>
	</dependencies>
</dependencyManagement>

<dependencies>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-starter-config</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-test</artifactId>
		<scope>test</scope>
	</dependency>
</dependencies>

<build>
	<plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
	</plugins>
</build>

<!-- repositories also needed for snapshots and milestones -->

Jetzt können Sie eine Standard-Spring-Boot-Anwendung erstellen, z. B. den folgenden HTTP-Server:

@SpringBootApplication @RestController public class Application {

@RequestMapping("/")
public String home() {
    return "Hello World!";
}

public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
}

}

Wenn dieser HTTP-Server ausgeführt wird, übernimmt er die externe Konfiguration vom standardmäßigen lokalen Config Server (sofern dieser läuft) auf Port 8888. Um das Startverhalten zu ändern, können Sie den Speicherort des Config Servers über bootstrap.properties verändern (ähnlich wie application.properties, jedoch für die Bootstrap-Phase eines Anwendungskontexts), wie im folgenden Beispiel gezeigt:

spring.cloud.config.uri: http://myconfigserver.com

Standardmäßig wird application verwendet, wenn kein Anwendungsname festgelegt ist. Um den Namen zu ändern, kann die folgende Eigenschaft zur Datei bootstrap.properties hinzugefügt werden:

spring.application.name: myapp

NOTE: Wenn Sie die Eigenschaft ${spring.application.name} festlegen, setzen Sie Ihrem Anwendungsnamen nicht das reservierte Wort application- voran, um Probleme beim Auflösen der korrekten Property-Quelle zu vermeiden.

Die Bootstrap-Eigenschaften erscheinen im /env-Endpunkt als Property-Quelle mit hoher Priorität, wie im folgenden Beispiel gezeigt.

$ curl localhost:8080/env { "profiles":[], "configService:https://github.com/spring-cloud-samples/config-repo/bar.properties":{"foo":"bar"}, "servletContextInitParams":{}, "systemProperties":{...}, ... }

Eine Property-Quelle namens ```configService:/enthält die Eigenschaftfoomit einem Wert vonbar` und hat höchste Priorität.

NOTE: Die URL im Namen der Property-Quelle ist das Git-Repository, nicht die Config-Server-URL.

=== Beispielanwendung

Eine Beispielanwendung finden Sie https://github.com/spring-cloud/spring-cloud-config/tree/master/spring-cloud-config-sample[hier]. Es ist eine Spring-Boot-Anwendung, sodass Sie sie mit den üblichen Mechanismen ausführen können (z. B. mvn spring-boot:run). Wenn sie läuft, sucht sie den Config Server unter http://localhost:8888 (ein konfigurierbarer Standardwert), sodass Sie auch den Server ausführen können, um zu sehen, wie alles zusammenarbeitet.

Das Beispiel enthält einen Testfall, bei dem der Config Server ebenfalls in derselben JVM gestartet wird (mit einem anderen Port), und der Test stellt sicher, dass eine Umgebungseigenschaft aus dem Git-Konfigurations-Repository vorhanden ist. Um den Speicherort des Config Servers zu ändern, können Sie spring.cloud.config.uri in bootstrap.yml festlegen (oder in Systemeigenschaften und anderen Orten).

Der Testfall enthält eine main()-Methode, die den Server auf dieselbe Weise ausführt (beobachten Sie die Logs, um dessen Port zu erfahren), sodass Sie das gesamte System in einem Prozess ausführen und damit experimentieren können (z. B. können Sie die main()-Methode in Ihrer IDE ausführen). Die main()-Methode verwendet target/config als Arbeitsverzeichnis des Git-Repositorys, sodass Sie dort lokale Änderungen vornehmen und sehen können, wie sie sich in der laufenden Anwendung widerspiegeln. Das folgende Beispiel zeigt eine Sitzung des Experimentierens mit dem Testfall:

$ curl localhost:8080/env/sample mytest $ vi target/config/mytest.properties .. change value of "sample", optionally commit $ curl localhost:8080/refresh ["sample"] $ curl localhost:8080/env/sample sampleValue

Der Refresh-Endpunkt meldet, dass die Eigenschaft „sample“ geändert wurde.

== Erstellen

:jdkversion: 1.7

=== Grundlegendes Kompilieren und Testen

Um die Quellen zu erstellen, müssen Sie JDK {jdkversion} installieren.

Spring Cloud verwendet Maven für die meisten Build-Aktivitäten. Sie sollten relativ schnell loslegen können, indem Sie das Projekt klonen, an dem Sie interessiert sind, und Folgendes eingeben:

$ ./mvnw install

NOTE: Sie können Maven (>=3.3.3) auch selbst installieren und in den folgenden Beispielen den Befehl mvn anstelle von ./mvnw ausführen. In diesem Fall müssen Sie möglicherweise auch -P spring hinzufügen, wenn Ihre lokalen Maven-Einstellungen keine Repository-Deklarationen für Spring-Pre-Release-Artefakte enthalten.

NOTE: Beachten Sie, dass Sie möglicherweise den für Maven verfügbaren Arbeitsspeicher erhöhen müssen, indem Sie eine Umgebungsvariable MAVEN_OPTS mit einem Wert wie -Xmx512m -XX:MaxPermSize=128m setzen. Wir versuchen, dies in der .mvn-Konfiguration abzudecken. Wenn Sie also feststellen, dass Sie dies tun müssen, damit ein Build erfolgreich ist, reichen Sie bitte ein Ticket ein, damit die Einstellungen zur Versionsverwaltung hinzugefügt werden.

Hinweise zum Erstellen des Projekts finden Sie – falls vorhanden – in .travis.yml. Dort sollte es einen „script“- und möglicherweise einen „install“-Befehl geben. Sehen Sie sich außerdem den Abschnitt „services“ an, um festzustellen, ob Dienste lokal ausgeführt werden müssen (z. B. Mongo oder Rabbit). Ignorieren Sie die Git-bezogenen Teile, die Sie möglicherweise in „before_install“ finden, da sie mit der Einrichtung von Git-Anmeldeinformationen zusammenhängen und Sie diese bereits haben.

Projekte, die Middleware benötigen, enthalten in der Regel eine docker-compose.yml. Ziehen Sie daher in Betracht, https://docs.docker.com/compose/[Docker Compose] zu verwenden, um die Middleware-Server in Docker-Containern auszuführen. Siehe die README im https://github.com/spring-cloud-samples/scripts[Skript-Demo- Repository] für spezifische Anweisungen zu den gängigen Fällen von Mongo, Rabbit und Redis.

NOTE: Wenn alles andere fehlschlägt, erstellen Sie mit dem Befehl aus .travis.yml (normalerweise ./mvnw install).

=== Dokumentation

Das Modul spring-cloud-build verfügt über ein Profil „docs“. Wenn Sie dieses aktivieren, wird versucht, Asciidoc-Quellen aus src/main/asciidoc zu erstellen. Im Rahmen dieses Prozesses wird nach einer README.adoc gesucht und diese verarbeitet, indem alle Includes geladen werden. Die Datei wird jedoch nicht geparst oder gerendert, sondern nur nach ${main.basedir} kopiert (Standardwert: ${basedir}, also das Projektverzeichnis). Wenn es Änderungen an der README gibt, erscheinen diese nach einem Maven-Build als geänderte Datei an der richtigen Stelle. Committen Sie sie einfach und pushen Sie die Änderung.

=== Arbeiten mit dem Code

Wenn Sie keine IDE-Präferenz haben, empfehlen wir, bei der Arbeit mit dem Code https://www.springsource.com/developer/sts[Spring Tools Suite] oder https://eclipse.org[Eclipse] zu verwenden. Für die Maven-Unterstützung verwenden wir das https://eclipse.org/m2e/[m2eclipse]-Eclipse-Plugin. Andere IDEs und Werkzeuge sollten ebenfalls problemlos funktionieren, solange sie Maven 3.3.3 oder besser verwenden.

==== Importieren in Eclipse mit m2eclipse

Wir empfehlen das https://eclipse.org/m2e/[m2eclipse]-Eclipse-Plugin für die Arbeit mit Eclipse. Falls Sie m2eclipse noch nicht installiert haben, finden Sie es im „Eclipse Marketplace“.

NOTE: Ältere Versionen von m2e unterstützen Maven 3.3 nicht. Sobald die Projekte in Eclipse importiert sind, müssen Sie m2eclipse daher anweisen, das richtige Profil für die Projekte zu verwenden. Wenn Sie viele verschiedene Fehler im Zusammenhang mit den POMs in den Projekten sehen, überprüfen Sie, ob Ihre Installation aktuell ist. Wenn Sie m2e nicht aktualisieren können, fügen Sie Ihrem settings.xml das Profil „spring“ hinzu. Alternativ können Sie die Repository-Einstellungen aus dem Profil „spring“ des Parent-POMs in Ihre settings.xml kopieren.

==== Importieren in Eclipse ohne m2eclipse

Wenn Sie m2eclipse nicht verwenden möchten, können Sie die Eclipse-Projektmetadaten mit dem folgenden Befehl generieren:

[indent=0]

$ ./mvnw eclipse:eclipse

Die generierten Eclipse-Projekte können importiert werden, indem Sie im Menü file die Option import existing projects auswählen.

=== JCE

Wenn Sie eine Ausnahme wegen „Illegal key size“ erhalten und das Sun-JDK verwenden, müssen Sie die Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files installieren. Weitere Informationen finden Sie unter den folgenden Links:

https://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html[Java 6 JCE]

https://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html[Java 7 JCE]

https://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html[Java 8 JCE]

Extrahieren Sie die JCE-Dateien in den Ordner JDK/jre/lib/security für die jeweilige Version von JRE/JDK x64/x86, die Sie verwenden.

== Mitwirken

:spring-cloud-build-branch: master

Spring Cloud wird unter der freizügigen Apache-2.0-Lizenz veröffentlicht und folgt einem sehr standardmäßigen GitHub-Entwicklungsprozess: Der GitHub-Tracker wird für Issues verwendet, und Pull Requests werden in den Master gemergt. Wenn Sie etwas beitragen möchten, auch etwas Triviales, zögern Sie bitte nicht, sondern befolgen Sie die folgenden Richtlinien.

=== Unterzeichnung der Contributor License Agreement

Bevor wir einen nicht-trivialen Patch oder Pull Request annehmen, müssen Sie die https://cla.pivotal.io/sign/spring[Contributor License Agreement] unterzeichnen. Die Unterzeichnung der Contributor License Agreement gewährt niemandem Commit-Rechte am Haupt-Repository, bedeutet aber, dass wir Ihre Beiträge annehmen können, und Sie erhalten eine Autorennennung, wenn wir dies tun. Aktive Mitwirkende werden möglicherweise gebeten, dem Kern-Team beizutreten, und erhalten die Möglichkeit, Pull Requests zu mergen.

=== Verhaltenskodex

Dieses Projekt hält sich an den Contributor Covenant https://github.com/spring-cloud/spring-cloud-build/blob/master/docs/src/main/asciidoc/code-of-conduct.adoc[Verhaltens- kodex]. Durch Ihre Teilnahme wird erwartet, dass Sie diesen Kodex einhalten. Bitte melden Sie inakzeptables Verhalten an [email protected].

=== Code-Konventionen und Projektpflege

Keiner dieser Punkte ist für einen Pull Request zwingend erforderlich, aber alle helfen. Sie können auch nach dem ursprünglichen Pull Request, aber vor einem Merge hinzugefügt werden.

• Verwenden Sie die Code-Formatierungs-Konventionen des Spring Framework. Wenn Sie Eclipse verwenden, können Sie die Formatierungs-Einstellungen mithilfe der Datei eclipse-code-formatter.xml aus dem https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/spring-cloud-dependencies-parent/eclipse-code-formatter.xml[Spring Cloud Build]-Projekt importieren. Wenn Sie IntelliJ verwenden, können Sie das https://plugins.jetbrains.com/plugin/6546[Eclipse Code Formatter Plugin] verwenden, um dieselbe Datei zu importieren.
• Stellen Sie sicher, dass alle neuen .java-Dateien einen einfachen Javadoc-Klassenkommentar mit mindestens einem @author-Tag enthalten, der Sie identifiziert, und idealerweise mindestens einen Absatz darüber, wofür die Klasse gedacht ist.
• Fügen Sie allen neuen .java-Dateien den ASF-Lizenzkopf hinzu (kopieren Sie ihn aus vorhandenen Dateien im Projekt).
• Fügen Sie sich selbst als @author zu den .java-Dateien hinzu, die Sie wesentlich ändern (mehr als kosmetische Änderungen).
• Fügen Sie einige Javadocs hinzu und, wenn Sie den Namespace ändern, einige XSD-Dokumentelemente.
• Ein paar Unit-Tests würden ebenfalls sehr helfen -- jemand muss es ja tun.
• Wenn niemand sonst Ihren Branch verwendet, führen Sie bitte einen Rebase gegen den aktuellen Master (oder einen anderen Ziel-Branch im Hauptprojekt) durch.
• Befolgen Sie beim Schreiben einer Commit-Nachricht bitte https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[diese Konventionen]. Wenn Sie ein bestehendes Issue beheben, fügen Sie bitte Fixes gh-XXXX am Ende der Commit-Nachricht hinzu (wobei XXXX die Issue-Nummer ist).

=== Checkstyle

Spring Cloud Build enthält eine Reihe von Checkstyle-Regeln. Sie finden sie im Modul spring-cloud-build-tools. Die wichtigsten Dateien in diesem Modul sind:

.spring-cloud-build-tools/

└── src    ├── checkstyle    │   └── checkstyle-suppressions.xml <3>    └── main    └── resources    ├── checkstyle-header.txt <2>    └── checkstyle.xml <1>

<1> Standard-Checkstyle-Regeln <2> Dateikopf-Einrichtung <3> Standard-Unterdrückungsregeln

==== Checkstyle-Konfiguration

Checkstyle-Regeln sind standardmäßig deaktiviert. Um Checkstyle zu Ihrem Projekt hinzuzufügen, definieren Sie einfach die folgenden Eigenschaften und Plugins.

.pom.xml

<reporting>
    <plugins>
        <plugin> <5>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-checkstyle-plugin</artifactId>
        </plugin>
    </plugins>
</reporting>

Wenn Sie einige Regeln unterdrücken müssen (z. B. wenn die Zeilenlänge länger sein muss), reicht es aus, eine Datei unter ${project.root}/src/checkstyle/checkstyle-suppressions.xml mit Ihren Unterdrückungen zu definieren. Beispiel:.projectRoot/src/checkstyle/checkstyle-suppresions.xml

Es ist empfehlenswert, die Dateien ${spring-cloud-build.rootFolder}/.editorconfig und ${spring-cloud-build.rootFolder}/.springformat in Ihr Projekt zu kopieren. Auf diese Weise werden einige Standard-Formatierungsregeln angewendet. Sie können dies tun, indem Sie dieses Skript ausführen:```bash $ curl https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/.editorconfig -o .editorconfig $ touch .springformat

=== IDE-Einrichtung

==== Intellij IDEA

Um Intellij einzurichten, sollten Sie unsere Codierungskonventionen und Inspektionsprofile importieren und das Checkstyle-Plugin einrichten. Die folgenden Dateien finden Sie im Projekt https://github.com/spring-cloud/spring-cloud-build/tree/master/spring-cloud-build-tools[Spring Cloud Build].

.spring-cloud-build-tools/
----
└── src
    ├── checkstyle
    │   └── checkstyle-suppressions.xml <3>
    └── main
        └── resources
            ├── checkstyle-header.txt <2>
            ├── checkstyle.xml <1>
            └── intellij
                ├── Intellij_Project_Defaults.xml <4>
                └── Intellij_Spring_Boot_Java_Conventions.xml <5>
----
<1> Standardregeln für Checkstyle
<2> Dateikopf-Einrichtung
<3> Standard-Unterdrückungsregeln
<4> Projektstandards für Intellij, die die meisten Checkstyle-Regeln anwenden
<5> Projektstil-Konventionen für Intellij, die die meisten Checkstyle-Regeln anwenden

.Code-Stil

image::https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/{spring-cloud-build-branch}/docs/src/main/asciidoc/images/intellij-code-style.png[Code-Stil]

Gehen Sie zu `Datei` -> `Einstellungen` -> `Editor` -> `Code-Stil`. Klicken Sie dort auf das Symbol neben dem Abschnitt `Schema`. Klicken Sie dort auf den Wert `Schema importieren` und wählen Sie die Option `Intellij IDEA code style XML`. Importieren Sie die Datei `spring-cloud-build-tools/src/main/resources/intellij/Intellij_Spring_Boot_Java_Conventions.xml`.

.Inspektionsprofile

image::https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/{spring-cloud-build-branch}/docs/src/main/asciidoc/images/intellij-inspections.png[Code-Stil]

Gehen Sie zu `Datei` -> `Einstellungen` -> `Editor` -> `Inspektionen`. Klicken Sie dort auf das Symbol neben dem Abschnitt `Profil`. Klicken Sie dort auf `Profil importieren` und importieren Sie die Datei `spring-cloud-build-tools/src/main/resources/intellij/Intellij_Project_Defaults.xml`.

.Checkstyle

Damit Intellij mit Checkstyle funktioniert, müssen Sie das Plugin `Checkstyle` installieren. Es ist empfehlenswert, auch `Assertions2Assertj` zu installieren, um die JUnit-Assertions automatisch zu konvertieren.

image::https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/{spring-cloud-build-branch}/docs/src/main/asciidoc/images/intellij-checkstyle.png[Checkstyle]

Gehen Sie zu `Datei` -> `Einstellungen` -> `Weitere Einstellungen` -> `Checkstyle`. Klicken Sie dort im Abschnitt `Konfigurationsdatei` auf das `+`-Symbol. Dort müssen Sie festlegen, woher die Checkstyle-Regeln bezogen werden sollen. Im obigen Bild haben wir die Regeln aus dem geklonten Repository von Spring Cloud Build ausgewählt. Sie können jedoch auf das GitHub-Repository von Spring Cloud Build verweisen (z. B. für die `checkstyle.xml` : `https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/spring-cloud-build-tools/src/main/resources/checkstyle.xml`). Wir müssen die folgenden Variablen angeben:

- `checkstyle.header.file` – bitte verweisen Sie auf die Datei `spring-cloud-build-tools/src/main/resources/checkstyle-header.txt` von Spring Cloud Build, entweder in Ihrem geklonten Repository oder über die URL `https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/spring-cloud-build-tools/src/main/resources/checkstyle-header.txt`.
- `checkstyle.suppressions.file` – Standard-Unterdrückungen. Bitte verweisen Sie auf die Datei `spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml` von Spring Cloud Build, entweder in Ihrem geklonten Repository oder über die URL `https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml`.
- `checkstyle.additional.suppressions.file` – diese Variable entspricht den Unterdrückungen in Ihrem lokalen Projekt. Wenn Sie z. B. an `spring-cloud-contract` arbeiten, verweisen Sie auf den Ordner `project-root/src/checkstyle/checkstyle-suppressions.xml`. Ein Beispiel für `spring-cloud-contract` wäre: `/home/username/spring-cloud-contract/src/checkstyle/checkstyle-suppressions.xml`.

WICHTIG: Denken Sie daran, den `Scan-Bereich` auf `Alle Quellen` zu setzen, da wir Checkstyle-Regeln für Produktions- und Testquellen anwenden.