web-dev-qa-db-fra.com

Meilleure façon de structurer un référentiel Git pour Maven

J'ai besoin de quelques conseils pour structurer nos projets dans Git. Nous utilisons Java et Maven est notre outil de construction. Maven suppose un peu que tous vos projets ont éventuellement un ancêtre commun. Maven peut également être une véritable reine du drame lorsque les choses ne sont pas configurées exactement la façon dont la fondation Apache configure ses projets (toute personne utilisant le plugin de publication sait probablement de quoi je parle).

Nous voulons un pom parent de niveau supérieur qui contrôle les versions des plugins et la configuration de la construction (configuration du référentiel, quels artefacts à construire, conventions de dénomination, versions des plugins, etc.). Maven voudrait que tous nos projets informatiques soient dans les sous-dossiers de ce projet principal. Cela implique un repo Git massif pour l'organisation.

Cela créera un environnement très bruyant. S'il y a deux équipes travaillant sur des projets non liés, elles devront constamment retirer les fusions de l'autre équipe. Idéalement, j'aimerais avoir un dépôt par projet.

Mais ce genre de conflits avec le modèle extrêmement hiérarchique de Maven, qui exige les sous-projets soient des sous-dossiers.

J'ai besoin de conseils sur la façon dont les gens ont concilié ces deux modèles ... merci!

javaversion-controlgitmaven
19
Jonathan S. Fisher

Vous avez 2 options:
1. par git way: utilisez des sous-modules. Voici une documentation sur la façon dont git gère les sous-modules git submodules . Personnellement, je ne l'ai pas utilisé, mais cela semble correspondre à votre problème.
2. par voie maven: dans maven il n'est pas obligatoire que votre projet racine (configuration) soit hiérarchiquement le répertoire parent de tous vos projets. Vous pouvez avoir une structure comme ça:

configuration
 +-- pom.xml (configuration:XXX)
project1
 +-- pom.xml (project1:1.0-SNAPSHOT)
 !
 +-- module11 
 !     +-- pom.xml (1.0-SNAPSHOT)
 +-- module12
       +-- pom.xml (1.0-SNAPSHOT)
project2
 +-- pom.xml (project2:2.0-SNAPSHOT)
 !
 +-- module21 
 !     +-- pom.xml (2.0-SNAPSHOT)
 +-- module22
       +-- pom.xml (2.0-SNAPSHOT)

configuration, project1 et project2 sont au même niveau de répertoire et chacun pourrait être un référentiel git. Lorsque vous générez projet1 ou projet2, vous exécutez la commande maven à partir du niveau projet1 ou projet2 et maven essaiera de récupérer le parent (configuration) du référentiel maven et non du répertoire parent. Vous devez faire attention aux versions. Je recommanderais dans project1 ou project2 de conserver une référence à un parent (configuration) avec une version finale. Pour créer une version, vous devez le faire en 2 étapes: libérer la configuration en premier et libérer le projet en second. Project1 et project2 peuvent évoluer indépendamment et n'ont pas besoin d'avoir la même version de configuration qu'un parent.

Juste pour des cas particuliers lorsque vous souhaitez avoir à la fois la configuration et les projets en tant que versions d'instantané, dans project1 ou project2, vous pouvez utiliser le <relativePath> tag à l'intérieur <parent> tag pour pointer vers votre chemin de configuration local. Je ne le recommande pas car cela créera des problèmes sur l'environnement de développement (au moins pour moi dans Eclipse)

Je m'excuse pour mon anglais.

20
catta

Maven voudrait que tous nos projets informatiques soient dans les sous-dossiers de ce projet principal

Non, Maven veut simplement pouvoir récupérer les artefacts dont il a besoin. La meilleure façon de le faire est d'utiliser un référentiel d'artefacts, tel que Nexus ou Artifactory . Chaque projet peut avoir son propre référentiel Git.

Nous voulons un pom parent de niveau supérieur qui contrôle les versions des plugins et la configuration de la construction (configuration du référentiel, quels artefacts à construire , les conventions de dénomination, les versions des plugins, etc.

Voilà votre vrai problème. Il est logique d'utiliser un POM parent pour appliquer la configuration, mais il n'y a aucune raison de combiner la configuration avec le contrôle de génération. En fait, sauf pour un projet autonome à plusieurs modules, je dirais que c'est une très mauvaise idée, pour les seules raisons que vous énoncez (plus le fait que vous auriez à construire tous vos projets, tous le temps).

3
parsifal