Question Structure de projet multi-modules Maven


Je construis une application distribuée qui est basée sur une API HTTP frontale (à lire sur le Web) qui fait appel à des Thrift Services sous-jacents (à lire: non orientés Web).

Par exemple, je peux avoir:

  • service d'authentification (contient le code pour l'authentification)
  • service de base (contient les sources d'épargne générées et certaines classes courantes telles que la découverte de services et la logique d'initialisation)

Tous les services individuels dépendent des services centraux, tout comme l'API HTTP Web. Je l'ai comme un projet multi-module en ce moment, mais je voudrais que chacun soit séparé (et suivi dans ses propres référentiels - même si je sais que je pourrais encore le faire avec une construction multi-module).

tl; dr -

Est-ce une pratique courante de construire un module (core-service) qui est construit individuellement puis poussé à un repo maven (puis inclus comme jar dans les autres projets), ou serait-il préférable dans ce cas de faire un projet multi-module?


12
2018-06-17 11:44


origine


Réponses:


Personnellement, j'essaie d'éviter les projets multi-modules car, si vous utilisez le Maven Release Plugin, vous êtes obligé de libérer tous vos modules ensemble.

Bien que cela puisse sembler pratique, le problème survient lorsque vous devez publier une version de correction de bogue sur l'un des modules - vous finissez par libérer tous les modules, pas seulement le module avec le correctif, en incrémentant leur version même s'ils ne l'ont pas modifié.

Si vous exécutez CI avec des projets multi-modules, vous obtenez également un coup: vous construisez généralement sur tous les modules de root pom, mais si vous travaillez dans un module particulier, vous finissez par les générer. qui n'ont pas changé, perdant ainsi certains des avantages de la modularisation.

Donc, allez avec des modules indépendants mais, et c'est le bit important, créez un pom de «dépendance» commun utilisé par chacun.

Un pom de «dépendance» est un pom qui normalise toutes les dépendances dans vos projets et est différent en ce sens que ces dépendances sont spécifiées dans le dependencyManagement section plutôt que la dependencies section (il configure également la configuration standard du plugin, etc.). Cela permet à vos poms de projet de spécifier le pom de dépendance comme leur parent et de déclarer ensuite les dépendances dont ils ont besoin moins les versions, qui sont extraites du pom de «dépendance» et ainsi standardisées dans tous vos projets.

Si vous êtes toujours soucieux de pouvoir tout construire, vous pouvez le faire avec un simple fichier de commandes.


14
2018-06-17 12:04



Je dirais que le projet multi-module est mieux. En cas de placement du service de base dans le référentiel, les développeurs doivent se soucier des versions. Developer1 a besoin de l'ancien service, mais Developer2 met à jour le service.

Des branches multiples pourraient également poser problème.


7
2018-06-17 11:56



Une version multi-module doit être privilégiée lorsque tous les modules individuels auront le même cycle de vie les uns que les autres ... en d'autres termes, lorsqu'ils sont toujours libérés ensemble, leurs numéros de version sont incrémentés ensemble, etc., etc.

Un bon exemple de cela dans le monde de l’OSS est le projet apache camel. Par exemple, tous les composants groupés existent en tant que modules individuels qui peuvent être inclus séparément dans votre projet, mais sont liés au même cycle de vie que la distribution de base de chameau.

Les versions multi-modules de Maven permettent certaines commodités lorsqu'il s'agit de placer vos projets dans CI ou de les charger dans des IDE par exemple, mais de manière générale, si tous les modules individuels ne partagent pas le même cycle de vie, alors un projet multi-modules n'est pas un bon ajustement


5
2018-06-17 12:43



En principe, il est toujours préférable que vos projets évoluent de manière aussi indépendante que possible. Cependant, il s’agit plutôt d’un problème d’organisation plutôt que d’un problème technique. En fin de compte, la structure de votre projet doit être cohérente avec votre organisation.

Cela revient à garder les projets séparés et à faire en sorte que les projets dépendants gèrent les dépendances au moyen d'un gestionnaire de référentiel local s'ils sont gérés par des personnes différentes ou s'il est judicieux de les publier à différents moments. Sinon, vous êtes probablement mieux avec une structure de projet multi-modules.

Dans notre projet, nous avons opté pour une sorte de choix intermédiaire: nous avons une structure multi-modules, mais tous les projets résident dans des référentiels Subversion indépendants, de sorte qu'ils peuvent être branchés séparément, et nous utilisons le projet d'agrégation pour choisir comment mélanger et associer des projets de différentes branches au moyen de svn:externals afin de créer des versions personnalisées pour des clients spécifiques.

L'inconvénient est que le maintien d'une structure similaire est compliqué et prend du temps. Nous avons développé une quantité importante de scripts pour automatiser partiellement ces tâches. Ceci est particulièrement contraignant parce que Maven release plugin n'est pas capable de traiter des modules connectés à l'aide d'externes Subversion.


3
2018-06-17 12:03