Introduction : qu'est-ce qu'un monorepo et pourquoi un développeur Java en a-t-il besoin ?
Imaginez que vous écrivez une grande application Java : un service web, une bibliothèque pour travailler avec des bases de données et un module séparé pour la journalisation. Traditionnellement, chaque composant est stocké dans son propre dépôt Git. Mais il existe une autre approche — le monorepo (monorepository). C'est une stratégie où tout le code d'un projet (ou même de plusieurs projets liés) est stocké dans un seul dépôt.
Pour les développeurs Java débutants, le monorepo peut sembler inhabituel, mais il offre des avantages importants :
- Version unique des dépendances — tous les modules utilisent les mêmes versions de bibliothèques, ce qui élimine les conflits.
- Refactoring simplifié — une modification de l'API dans un module est immédiatement visible dans tous les modules dépendants.
- Paramètres communs — un seul fichier de configuration pour le linter, le formatage et le CI/CD.
- Démarrage facile — pas besoin de configurer plusieurs dépôts pour un petit projet.
Dans cet article, nous allons voir comment organiser un monorepo en Java en utilisant des outils de build populaires : Maven et Gradle. Vous apprendrez à structurer les dossiers, à configurer un build multi-modules et à éviter les erreurs typiques.
Partie principale
1. Structure du monorepo : du simple au complexe
Une structure de dossiers correcte est la base d'un monorepo réussi. Voici un modèle recommandé pour un projet Java :
my-monorepo/├── build.gradle # Fichier de build racine (pour Gradle)├── settings.gradle # Liste des modules├── pom.xml # POM racine (pour Maven)├── README.md├── .gitignore├── libs/ # Bibliothèques communes│ ├── common-utils/│ └── logging-framework/├── services/ # Microservices ou applications│ ├── user-service/│ └── payment-service/└── tools/ # Utilitaires et scripts └── code-generator/Chaque module est un projet Java indépendant avec son propre pom.xml ou build.gradle. Les fichiers de configuration racine gèrent les dépendances et les versions. Examinons les deux options plus en détail.
2. Monorepo avec Maven : projet multi-modules
Maven prend en charge les projets multi-modules nativement. Créez un pom.xml racine avec la liste des modules :
<project> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>my-monorepo</artifactId> <packaging>pom</packaging> <version>1.0.0</version> <modules> <module>libs/common-utils</module> <module>services/user-service</module> <module>services/payment-service</module> </modules>
<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>3.2.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement></project>Dans le module common-utils (dossier libs/common-utils), créez votre propre pom.xml qui fait référence au projet parent :
<project> <parent> <groupId>com.example</groupId> <artifactId>my-monorepo</artifactId> <version>1.0.0</version> </parent> <artifactId>common-utils</artifactId> <dependencies> <dependency>