Pourquoi décomposer un projet Maven aux sous-modules?

Question

Quelles sont les principales raisons possibles de décomposer un projet Maven aux sous-modules?

Answer 1

Vous cherchez quelque chose de plus que les avantages de la modularisation? Les sous-modules devraient idéalement être représentant un concept unique / fonctionnalité afin qu'ils soient fonctionnellement cohésif.

Answer 2

• fichier Pom inheritence Vous pouvez utiliser les sections et des poms root pour conserver les numéros de version cohérente et configurations pour tous les projets enfants. Donc, si j'ai un projet d'agrégation que les listes 300 projets, tout ce qui utilisent apache commons-io et je veux les mettre à jour toutes les la dernière version des communes-io, je peux changer la version dans la section dependencyManagement de la pom racine. Aucun des projets d'enfant doit spécifier une version.
• profils de construction Dans l'exemple ci-dessus, si j'ai 300 sous-projets, un développeur individuel est probablement pas travailler régulièrement sur tous (ou même plusieurs) des 300 sous-projets. Vous pouvez créer un profil de construction qui spécifie que les modules que vous travaillez sur régulièrement, et si vous avez un serveur d'intégration continue qui déploie des artefacts à un dépôt d'artefact, vous obtiendrez tous les changements que les développeurs sur votre marque d'équipe aussi, sans avoir à construire tous les 300 modules.
• Organisation générale / clarté

Answer 3

En attendant une réponse à mon commentaire.

• Une raison de diviser un projet Maven Java EE en sous-modules est de sorte que vous pouvez construire le JAR / RAR / WAR / EAR / whatever indépendamment de eachother.

• Pour les applications régulières Java, vous pourriez diviser la fonctionnalité dans des jarres séparés, encore une fois chacun d'entre eux pourrait être un sous-module dans le cadre du projet dans son ensemble et encore, vous pouvez les construire de manière indépendante, exécuter des objectifs distincts / phases / rapports etc.