Pour être simple, Spring, c’est le framework de base. Il est composé de plusieurs fonctionnalités intéressantes comme l’injection de dépendances et des modules prets à l’emploi tels que :
Spring Boot, quant à lui, c’est une couche posée par dessus de Spring. Il ne remplace pas Spring car sous le capot, on a toujours ce dernier qui tourne. Donc son rôle, c’est de supprimer presque toute cette configuration manuelle grâce à trois mécanismes.
Le site est construit avec Jekyll et le thème TeXt, hébergé sur GitHub Pages. Le code source est disponible sur GitHub si ça vous intéresse.
À bientôt pour le premier vrai article !
]]>Maven est un outil de gestion de projet et de build pour Java (et les autres langages JVM comme Kotlin ou Scala). Il s’appuie sur un fichier de configuration unique, le pom.xml, qui décrit tout ce dont ton projet a besoin.
Son rôle :
En résumé, il automatise tout ce qui est répétitif dans un cycle de développement.
mon-projet/
│
├── pom.xml # fichier principal, la "recette" du build
└── src/
├── main/
│ ├── java/ # code source
│ └── resources/ # fichiers de configuration
└── test/
├── java/ # tests unitaires
└── resources/ # fichiers de test
pom.xml : le cœur du projet — dépendances, plugins, métadonnéessrc/main/java : ton code sourcesrc/test/java : tes tests unitaires (JUnit, TestNG…)pom.xml minimal<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<groupId>com.exemple</groupId>
<artifactId>mon-projet</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<properties>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<version>5.10.0</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
Les éléments clés :
com.entreprise)SNAPSHOT = en développement, pas encore figée)jar, war, pom pour un projet parent multi-modules…)Maven exécute les tâches selon un cycle de vie prédéfini : chaque phase déclenche automatiquement toutes celles qui la précèdent.
| Phase | Rôle |
|---|---|
validate |
Vérifie que le projet est correctement configuré |
compile |
Compile le code source |
test |
Exécute les tests unitaires |
package |
Assemble le projet (jar, war…) |
install |
Installe le build dans le dépôt local (~/.m2), pour qu’il soit utilisable par d’autres projets sur la machine |
deploy |
Publie le build sur un dépôt distant (Nexus, Artifactory, Maven Central…) |
Lancer mvn install exécute donc automatiquement validate, compile, test et package avant lui.
| Commande | Description |
|---|---|
mvn clean |
Supprime les fichiers compilés (le dossier target/) |
mvn compile |
Compile le code source |
mvn test |
Exécute les tests unitaires |
mvn package |
Crée le jar/war exécutable |
mvn install |
Installe le projet dans le dépôt local |
mvn dependency:tree |
Affiche l’arbre complet des dépendances (utile pour traquer un conflit de versions) |
Une combinaison très courante avant de commit : mvn clean install, pour repartir d’un état propre.
Quand Maven télécharge une dépendance, il ne la retélécharge pas à chaque build : il la garde en cache dans le dépôt local, sur ta machine, dans ~/.m2/repository. Si une dépendance manque en local, Maven va la chercher sur un dépôt distant — par défaut, Maven Central.
Exemple d’ajout d’une dépendance :
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.13.0</version>
</dependency>
Il suffit d’ajouter ce bloc dans pom.xml : Maven télécharge le jar et toutes ses propres dépendances (dépendances transitives) automatiquement.
Les profils permettent de changer le comportement du build selon le contexte, sans toucher au reste du pom.xml. Exemples courants :
skip-tests pour ignorer les tests lors d’un build rapidedev, prod) pour adapter la configuration de déploiement<profiles>
<profile>
<id>skip-tests</id>
<properties>
<maven.test.skip>true</maven.test.skip>
</properties>
</profile>
</profiles>
Activation : mvn install -P skip-tests.
mvnw)Plutôt que de demander à chaque développeur d’installer Maven manuellement (et de risquer des versions différentes d’une machine à l’autre), la plupart des projets embarquent un Maven Wrapper : les scripts mvnw (Linux/Mac) et mvnw.cmd (Windows), à la racine du projet.
./mvnw clean install
Ça télécharge automatiquement la bonne version de Maven si besoin, et garantit que toute l’équipe (et la CI) utilise exactement la même version.
1.0-SNAPSHOT). Maven la retélécharge à chaque build si elle vient d’un dépôt distant, pour rester à jour.1.0.0), publiée une fois pour toutes — elle ne change plus jamais.Le flux classique sur un projet Maven :
mvn clean # nettoyer
mvn compile # compiler
mvn test # tester
mvn package # créer le jar/war
mvn install # installer localement
mvn deploy # envoyer sur un dépôt distant (optionnel)
Maven a un peu la réputation d’être verbeux (le XML n’aide pas), mais sa prévisibilité et la stabilité de son écosystème en font toujours un choix solide, notamment en entreprise. Si tu veux comparer avec une alternative plus moderne, Gradle mérite le détour — ce sera peut-être le sujet d’un prochain article.
]]>Au fil de mes projets (applications web, mobile, expérimentations diverses), j’accumule pas mal de retours d’expérience : des choix techniques qui ont payé, d’autres qui m’ont fait perdre du temps, des bugs tordus, des outils que je découvre. Ce blog va me servir à mettre tout ça au clair, et si ça peut aider quelqu’un d’autre au passage, tant mieux.
Le site est construit avec Jekyll et le thème TeXt, hébergé sur GitHub Pages. Le code source est disponible sur GitHub si ça vous intéresse.
À bientôt pour le premier vrai article !
]]>