Disposition du référentiel pour les grands projets Maven

Question

J'ai une grande application (~ 50 modules) utilisant une structure similaire à la suivante :

• Application
  • Modules de communication
    • Module de communication couleur
    • Module de communication SSN
    • etc.module de communication
  • Module routeur
  • Modules de services
    • Module de service de vote
      • Sous-module d'interface Web pour le vote
      • Sous-module collecteur de votes pour le vote
      • etc.pour voter
    • Module de service de quiz
    • etc.module

Je souhaite importer l'application vers Maven et Subversion.Après quelques recherches, j'ai découvert qu'il existe deux approches pratiques pour cela.

L’une utilise une structure arborescente tout comme la précédente.L'inconvénient de cette structure est que vous avez besoin d'une tonne de réglages/piratages pour que les rapports multi-modules fonctionnent correctement avec Maven.Un autre inconvénient est que dans Subversion, l'approche standard tronc/balises/branches ajoute encore plus de complexité au référentiel.

L'autre approche utilise une structure plate, dans laquelle il n'y a qu'un seul projet parent et tous les modules, sous-modules et parties de sous-modules sont des enfants directs du projet parent.Cette approche fonctionne bien pour le reporting et est plus facile dans Subversion, cependant j'ai l'impression de perdre un peu de la structure de cette façon.

Quelle voie choisiriez-vous à long terme et pourquoi ?

Answer 1

Nous avons une application de grande taille (plus de 160 bundles OSGi où chaque bundle est un module Maven) et la leçon que nous avons apprise et continuons d'apprendre est que le plat est meilleur.Le problème avec l’encodage de la sémantique dans votre hiérarchie est que vous perdez en flexibilité.Un module qui dit à 100 % "communication" aujourd'hui peut être en partie "service" demain et vous devrez alors déplacer des éléments dans votre référentiel, ce qui brisera toutes sortes de scripts, de documentation, de références, etc.

Je recommanderais donc une structure plate et d'encoder la sémantique dans un autre endroit (disons par exemple un espace de travail ou une documentation IDE).

J'ai répondu en détail à une question sur la disposition du contrôle de version. avec des exemples à une autre question, cela peut être pertinent à votre situation.

Answer 2

Je pense qu'il vaut mieux aplatir votre structure de répertoires.Peut-être souhaitez-vous proposer une convention de dénomination pour les répertoires de telle sorte qu'ils soient bien triés lors de la visualisation de tous les projets, mais en fin de compte, je ne pense pas que toute cette hiérarchie supplémentaire soit nécessaire.

En supposant que vous utilisez Eclipse comme IDE, tous les projets se retrouveront de toute façon dans une liste plate une fois que vous les importerez, vous ne gagnerez donc vraiment rien des sous-répertoires supplémentaires.Cela, en plus du fait que la configuration est beaucoup plus simple sans toute la hiérarchie supplémentaire, rend le choix assez clair dans mon esprit.

Vous pourriez également envisager de combiner certains modules.Je ne sais rien de votre application ou de votre domaine, mais il semble que beaucoup de ces modules de niveau feuille pourraient être mieux adaptés en tant que simples packages ou ensembles de packages dans un autre module de niveau supérieur.Je suis tout à fait favorable à la cohésion des pots, mais cela peut parfois aller trop loin.