spring cloud gateway
4.2.0
Java17
Cadre de printemps 6
Démarrage de printemps 3
Routage dynamique
Correspondance d'itinéraire intégrée à Spring Handler Mapping
Correspondance de route sur requête HTTP (Chemin, Méthode, En-tête, Hôte, etc…)
Filtres limités à l'itinéraire correspondant
Les filtres peuvent modifier la requête HTTP et la réponse HTTP en aval (Ajouter/Supprimer des en-têtes, Ajouter/Supprimer des paramètres, Réécrire le chemin, Définir le chemin, Hystrix, etc…)
Piloté par API ou configuration
Prend en charge Spring Cloud DiscoveryClient pour la configuration des routes
Directive non résolue dans <stdin> - include ::https:///raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/docs/modules/ROOT/partials/building.adoc[]
Spring Cloud est publié sous la licence non restrictive Apache 2.0 et suit un processus de développement Github très standard, utilisant le tracker Github pour les problèmes et fusionnant les demandes d'extraction dans le fichier principal. Si vous souhaitez contribuer, même quelque chose de trivial, n'hésitez pas, mais suivez les directives ci-dessous.
Avant d'accepter un correctif non trivial ou une pull request, nous aurons besoin que vous signiez le contrat de licence de contributeur. La signature de l'accord de contributeur n'accorde à personne de droits d'engagement sur le référentiel principal, mais cela signifie que nous pouvons accepter vos contributions, et vous obtiendrez un crédit d'auteur si nous le faisons. Les contributeurs actifs peuvent être invités à rejoindre l'équipe principale et avoir la possibilité de fusionner les demandes d'extraction.
Ce projet adhère au code de conduite Contributor Covenant. En participant, vous êtes censé respecter ce code. Veuillez signaler tout comportement inacceptable à [email protected].
Aucun de ces éléments n’est essentiel pour une pull request, mais ils seront tous utiles. Ils peuvent également être ajoutés après la pull request d'origine mais avant une fusion.
Utilisez les conventions de format de code Spring Framework. Si vous utilisez Eclipse, vous pouvez importer les paramètres du formateur à l'aide du fichier eclipse-code-formatter.xml du projet Spring Cloud Build. Si vous utilisez IntelliJ, vous pouvez utiliser le plugin Eclipse Code Formatter pour importer le même fichier.
Assurez-vous que tous les nouveaux fichiers .java contiennent un simple commentaire de classe Javadoc avec au moins une balise @author vous identifiant, et de préférence au moins un paragraphe expliquant à quoi sert la classe.
Ajoutez le commentaire d'en-tête de licence ASF à tous les nouveaux fichiers .java (copie à partir des fichiers existants dans le projet)
Ajoutez-vous en tant que @author aux fichiers .java que vous modifiez de manière substantielle (plus que des modifications cosmétiques).
Ajoutez des Javadocs et, si vous modifiez l'espace de noms, des éléments de documentation XSD.
Quelques tests unitaires seraient également très utiles : quelqu'un doit le faire.
Si personne d'autre n'utilise votre branche, veuillez la rebaser par rapport à la branche principale actuelle (ou à une autre branche cible du projet principal).
Lorsque vous rédigez un message de validation, veuillez suivre ces conventions. Si vous résolvez un problème existant, veuillez ajouter Fixes gh-XXXX à la fin du message de validation (où XXXX est le numéro du problème).
Spring Cloud Build est livré avec un ensemble de règles de style de contrôle. Vous pouvez les trouver dans le module spring-cloud-build-tools . Les fichiers les plus notables du module sont :
└──src ├── style de contrôle │ └── checkstyle-suppressions.xml (3) └── principal └── ressources ├── checkstyle-header.txt (2) └── checkstyle.xml (1)
Règles de style de contrôle par défaut
Configuration de l'en-tête de fichier
Règles de suppression par défaut
Les règles de style de contrôle sont désactivées par défaut . Pour ajouter un style de contrôle à votre projet, définissez simplement les propriétés et plugins suivants.
<propriétés>
<maven-checkstyle-plugin.failsOnError>true</maven-checkstyle-plugin.failsOnError> (1)
<maven-checkstyle-plugin.failsOnViolation>true
</maven-checkstyle-plugin.failsOnViolation> (2)
<maven-checkstyle-plugin.includeTestSourceDirectory>true
</maven-checkstyle-plugin.includeTestSourceDirectory> (3)
</propriétés>
<construire>
<plugins>
<plugin> (4)
<groupId>io.spring.javaformat</groupId>
<artifactId>spring-javaformat-maven-plugin</artifactId>
</plugin>
<plugin> (5)
<groupId>org.apache.maven.plugins</groupId>
<artifactId>plugin-maven-checkstyle-plugin</artifactId>
</plugin>
</plugins>
<rapport>
<plugins>
<plugin> (5)
<groupId>org.apache.maven.plugins</groupId>
<artifactId>plugin-maven-checkstyle-plugin</artifactId>
</plugin>
</plugins>
</rapport>
</build>Échec de la construction en cas d'erreurs Checkstyle
Échec de la construction en cas de violations de Checkstyle
Checkstyle analyse également les sources de test
Ajoutez le plugin Spring Java Format qui reformatera votre code pour passer la plupart des règles de formatage Checkstyle
Ajoutez le plugin checkstyle à vos phases de construction et de reporting
Si vous devez supprimer certaines règles (par exemple, la longueur de ligne doit être plus longue), alors il vous suffit de définir un fichier sous ${project.root}/src/checkstyle/checkstyle-suppressions.xml avec vos suppressions. Exemple:
<?xml version="1.0"?> <!DOCTYPE suppressions PUBLIC "-//Puppy Crawl//DTD Suppressions 1.1//EN" "https://www.puppycrawl.com/dtds/suppressions_1_1.dtd"> <suppressions> <suppress files=".*ConfigServerApplication.java" checks="HideUtilityClassConstructor"/> <suppress files=".*ConfigClientWatch.java" checks="LineLengthCheck"/> </suppressions>
Il est conseillé de copier les ${spring-cloud-build.rootFolder}/.editorconfig et ${spring-cloud-build.rootFolder}/.springformat dans votre projet. De cette façon, certaines règles de formatage par défaut seront appliquées. Vous pouvez le faire en exécutant ce script :
$ curl https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/.editorconfig -o .editorconfig
$ touch .springformatAfin de configurer Intellij, vous devez importer nos conventions de codage, nos profils d'inspection et configurer le plugin checkstyle. Les fichiers suivants se trouvent dans le projet Spring Cloud Build.
└──src
├── style de contrôle
│ └── checkstyle-suppressions.xml (3)
└── principal
└── ressources
├── checkstyle-header.txt (2)
├── checkstyle.xml (1)
└── intelligence
├── Intellij_Project_Defaults.xml (4)
└── Intellij_Spring_Boot_Java_Conventions.xml (5)Règles de style de contrôle par défaut
Configuration de l'en-tête de fichier
Règles de suppression par défaut
Valeurs par défaut du projet pour Intellij qui appliquent la plupart des règles Checkstyle
Conventions de style de projet pour Intellij qui appliquent la plupart des règles Checkstyle
Allez dans File → Settings → Editor → Code style . Là, cliquez sur l'icône à côté de la section Scheme . Là, cliquez sur la valeur Import Scheme et choisissez l’option Intellij IDEA code style XML . Importez le fichier spring-cloud-build-tools/src/main/resources/intellij/Intellij_Spring_Boot_Java_Conventions.xml .
Accédez à File → Settings → Editor → Inspections . Là, cliquez sur l'icône à côté de la section Profile . Là, cliquez sur le Import Profile et importez le fichier spring-cloud-build-tools/src/main/resources/intellij/Intellij_Project_Defaults.xml .
Pour qu'Intellij fonctionne avec Checkstyle, vous devez installer le plugin Checkstyle . Il est conseillé d'installer également Assertions2Assertj pour convertir automatiquement les assertions JUnit
Accédez à File → Settings → Other settings → Checkstyle . Cliquez là sur l'icône + dans la section Configuration file . Là, vous devrez définir où les règles de style de contrôle doivent être sélectionnées. Dans l'image ci-dessus, nous avons sélectionné les règles du référentiel Spring Cloud Build cloné. Cependant, vous pouvez pointer vers le référentiel GitHub de Spring Cloud Build (par exemple pour le checkstyle.xml : https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle.xml ). Nous devons fournir les variables suivantes :
checkstyle.header.file - veuillez le pointer vers le fichier Spring Cloud Build, spring-cloud-build-tools/src/main/resources/checkstyle-header.txt soit dans votre dépôt cloné, soit via https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle-header.txt URL https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle-header.txt .
checkstyle.suppressions.file - suppressions par défaut. Veuillez le pointer vers le fichier Spring Cloud Build, spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml soit dans votre dépôt cloné, soit via https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml URL.
checkstyle.additional.suppressions.file - cette variable correspond aux suppressions dans votre projet local. Par exemple, vous travaillez sur spring-cloud-contract . Pointez ensuite sur le dossier project-root/src/checkstyle/checkstyle-suppressions.xml . Un exemple de spring-cloud-contract serait : /home/username/spring-cloud-contract/src/checkstyle/checkstyle-suppressions.xml .
Important | N'oubliez pas de définir la Scan Scope sur All sources car nous appliquons des règles de style de contrôle pour les sources de production et de test. |
Spring Cloud Build apporte le basepom:duplicate-finder-maven-plugin , qui permet de signaler les classes et ressources en double et en conflit sur le chemin de classe Java.
Le chercheur de doublons est activé par défaut et s'exécutera lors de la phase verify de votre build Maven, mais il ne prendra effet dans votre projet que si vous ajoutez le duplicate-finder-maven-plugin à la section build du pom.xml du projet.
< build >
< plugins >
< plugin >
< groupId >org.basepom.maven</ groupId >
< artifactId >duplicate-finder-maven-plugin</ artifactId >
</ plugin >
</ plugins >
</ build >Pour les autres propriétés, nous avons défini les valeurs par défaut comme indiqué dans la documentation du plugin.
Vous pouvez facilement les remplacer, mais en définissant la valeur de la propriété sélectionnée avec le préfixe duplicate-finder-maven-plugin . Par exemple, définissez duplicate-finder-maven-plugin.skip sur true afin d'ignorer la vérification des doublons dans votre build.
Si vous devez ajouter ignoredClassPatterns ou ignoredResourcePatterns à votre configuration, assurez-vous de les ajouter dans la section de configuration du plugin de votre projet :
< build >
< plugins >
< plugin >
< groupId >org.basepom.maven</ groupId >
< artifactId >duplicate-finder-maven-plugin</ artifactId >
< configuration >
< ignoredClassPatterns >
< ignoredClassPattern >org.joda.time.base.BaseDateTime</ ignoredClassPattern >
< ignoredClassPattern >.*module-info</ ignoredClassPattern >
</ ignoredClassPatterns >
< ignoredResourcePatterns >
< ignoredResourcePattern >changelog.txt</ ignoredResourcePattern >
</ ignoredResourcePatterns >
</ configuration >
</ plugin >
</ plugins >
</ build >
