Structure d'un projet Spring Boot typique

L'organisation conventionnelle d'un projet Spring Boot

Lorsque vous générez un projet Spring Boot à l'aide de Spring Initializr, vous obtenez une structure de répertoires et de fichiers standardisée. Cette organisation suit les conventions établies par Maven et Gradle, les outils de build les plus couramment utilisés dans l'écosystème Java. Adopter cette structure facilite la compréhension du projet par d'autres développeurs et permet aux outils de fonctionner correctement sans configuration excessive. Elle favorise également la séparation claire entre le code source de l'application, les ressources de configuration et le code de test.

Comprendre cette structure est fondamental pour naviguer efficacement dans un projet Spring Boot, savoir où placer vos fichiers et comment le projet est construit et géré. Que vous utilisiez Maven ou Gradle, les principes fondamentaux de l'organisation restent très similaires. Examinons les composants clés de cette structure.

Le fichier de build : pom.xml (Maven) ou build.gradle (Gradle)

Au coeur de tout projet Spring Boot se trouve le fichier de build. Il définit comment votre projet est construit, quelles sont ses dépendances et comment il s'intègre à l'écosystème Spring Boot.

• pom.xml (pour les projets Maven) : Ce fichier XML décrit le projet selon le Project Object Model (POM) de Maven. Il contient des informations cruciales :
  • Les métadonnées du projet (groupId, artifactId, version, name, description).
  • Le parent POM (spring-boot-starter-parent), qui fournit une gestion centralisée des versions des dépendances et une configuration par défaut sensée.
  • Les propriétés (comme la version de Java : 17).
  • La section , où vous déclarez les "starters" Spring Boot (ex: spring-boot-starter-web) et d'autres bibliothèques nécessaires. Maven se chargera de télécharger ces dépendances et leurs dépendances transitives.
  • La section , qui contient notamment le plugin spring-boot-maven-plugin, essentiel pour créer des JAR exécutables et gérer le cycle de vie de l'application Spring Boot avec Maven.
• build.gradle (pour les projets Gradle) : Ce fichier utilise une syntaxe basée sur Groovy ou Kotlin (build.gradle.kts) pour décrire la construction du projet. Il remplit les mêmes fonctions que le pom.xml mais de manière souvent plus concise :
  • Déclaration des plugins (ex: id 'org.springframework.boot' version '...', id 'java').
  • Configuration des métadonnées du projet (group, version).
  • Configuration des dépendances dans le bloc dependencies { ... } (ex: implementation 'org.springframework.boot:spring-boot-starter-web').
  • Définition de la version Java (souvent via une `toolchain` ou les propriétés `sourceCompatibility` / `targetCompatibility`).
  • Configuration spécifique à Spring Boot gérée par le plugin Spring Boot pour Gradle.

Ce fichier est la pierre angulaire de la gestion de votre projet. C'est ici que vous ajouterez de nouvelles fonctionnalités (en ajoutant des starters) ou configurerez le processus de compilation et de packaging.

Le code source de l'application : src/main/java

Le répertoire src/main/java est l'endroit où réside tout le code source Java (ou Kotlin/Groovy) de votre application. C'est le coeur de votre logique métier. A l'intérieur de ce répertoire, vous trouverez une structure de packages basée sur le `Package name` que vous avez défini lors de la création du projet (par exemple, com/certiquizz/monappliboot).

Au sein de ce package racine, Spring Initializr génère une classe principale, souvent nommée d'après l'`Artifact` de votre projet suivi de `Application` (par exemple, MonAppliBootApplication.java). Cette classe est annotée avec @SpringBootApplication et contient la méthode main qui sert de point d'entrée pour démarrer l'application.

C'est également dans src/main/java que vous organiserez le reste de votre code en sous-packages selon les bonnes pratiques architecturales (par exemple, controller, service, repository, model, config, etc.). Maintenir une structure de packages claire et logique est essentiel pour la maintenabilité du projet à mesure qu'il grandit.

Les ressources de l'application : src/main/resources

Le répertoire src/main/resources est destiné à contenir tous les fichiers qui ne sont pas du code source mais qui sont nécessaires à l'exécution de l'application. Ces fichiers sont généralement inclus dans le classpath de l'application lors de la construction.

On y trouve typiquement :

• Fichiers de configuration : Le plus célèbre est application.properties (ou son équivalent YAML, application.yml). C'est ici que vous définissez les configurations spécifiques à Spring Boot et à votre application (port du serveur, configuration de la base de données, niveaux de log, etc.). Vous pouvez également y placer des fichiers de configuration spécifiques aux profils (ex: application-dev.properties, application-prod.yml).
• Templates de vues : Si vous développez une application web traditionnelle (pas seulement une API REST), vous placerez vos templates HTML (par exemple pour Thymeleaf, Freemarker) dans des sous-répertoires conventionnels comme templates/.
• Contenu statique : Les fichiers CSS, JavaScript, images, polices, etc., sont généralement placés dans un sous-répertoire nommé static/. Spring Boot est configuré par défaut pour servir le contenu de ce répertoire.
• Scripts de migration de base de données : Si vous utilisez des outils comme Flyway ou Liquibase, leurs scripts SQL ou XML/YAML sont souvent placés dans db/migration/ (pour Flyway) ou un emplacement similaire.
• Autres fichiers de ressources : Fichiers i18n (internationalisation), fichiers XML de configuration spécifiques (bien que moins courants avec Spring Boot), etc.

Code et ressources de test : src/test

Parallèlement à src/main, vous trouverez le répertoire src/test. Il est dédié exclusivement au code et aux ressources nécessaires pour tester votre application.

• src/test/java : Contient le code source de vos tests unitaires et d'intégration. La structure des packages dans ce répertoire devrait idéalement refléter celle de src/main/java pour faciliter la localisation des tests correspondant à une classe spécifique. Spring Initializr y génère souvent une classe de test de base pour vérifier que le contexte de l'application se charge correctement.
• src/test/resources : Similaire à src/main/resources, ce répertoire contient les fichiers de configuration ou les données nécessaires uniquement pour l'exécution des tests. Par exemple, vous pourriez y placer un fichier application-test.properties avec une configuration de base de données en mémoire spécifique aux tests, ou des fichiers JSON/XML utilisés comme données d'entrée/sortie pour vos tests.

Cette séparation claire entre le code principal et le code de test garantit que les classes et ressources de test ne sont pas incluses dans l'artefact final de l'application (le JAR ou WAR).

Autres éléments notables

En plus des répertoires principaux, vous pourriez rencontrer d'autres éléments à la racine de votre projet :

• .mvn/ et mvnw / mvnw.cmd (pour Maven) ou gradle/ et gradlew / gradlew.bat (pour Gradle) : Ce sont les "wrappers". Ils permettent d'exécuter les commandes Maven ou Gradle sans avoir besoin d'installer l'outil globalement sur la machine, garantissant que tous les développeurs utilisent la même version de l'outil de build pour le projet.
• target/ (Maven) ou build/ (Gradle) : Ces répertoires sont générés lors du processus de construction. Ils contiennent les classes compilées (.class), les ressources traitées, les rapports de test, et surtout l'artefact final de l'application (le fichier JAR ou WAR). Il est généralement recommandé d'ignorer ces répertoires dans votre système de contrôle de version (via .gitignore).
• .gitignore : Un fichier essentiel pour les projets utilisant Git, spécifiant les fichiers et répertoires qui ne doivent pas être suivis par le contrôle de version (comme les répertoires de build, les fichiers de configuration de l'IDE, etc.).

En résumé, la structure d'un projet Spring Boot est conçue pour être logique, conventionnelle et efficace, facilitant le développement, la maintenance et la collaboration.