Maven composition de projet de module multiples en ce qui concerne le partage des dépendances

Question

Il y a quelques questions similaires, mais rien comme ça. Comment gérez-vous cette situation (scénario typique):

Un projet de 8-11 projets enfants, ayant un artefact parent / projet et un projet principal qui pour la plupart des utilisations / autres comme les déclare modules.

Le problème est que tous les projets « strictement » partager uniquement les dépendances communes, comme testng, logging, apache commons and stuff. Mais toujours comme 3 d'entre eux utilisent 50-60% des mêmes deps spécifiques (apache-chimie, Jackrabbit, Abdère, etc.), un autre 2-3 d'entre eux utilisent également 50-60% des dépendances mêmes mais différents . Et le principal utilise beaucoup des mêmes DEPS.

Je ne peux pas mettre ces « non strictement » partagés DEPS dans le projet parent pour les autres de les hériter. Alors que les DEPS communes sont héritées. Et il y a des tonnes de dépendances en double. Et je ne peux gérer leurs versions via <dependencyManagement>.

Une autre option est d'avoir pom parent contient la plupart des dépendances, mais les projets enfants héritent même ceux qu'ils ne ont pas besoin.

Je pourrais avoir plus de 1 projet parent, mais il ne se sent pas bien. Aussi l'héritage du projet parent pourrait être cauchemar, parce que vous ne savez pas quelles dépendances les besoins du projet, si vous n'avez pas le document / commenter la définition de pom-mère correctement.

Une autre façon est de créer des artefacts pom qui sert uniquement comme des conteneurs de dépendance - ils déclarent certains groupes de dépendances, de sorte que les modules déclarent seulement ceux à gagner dépendances transitif. Mais bon, voulez-vous déployer et engager une sorte de

OneDepArtifact déclarant jackrabit, abdera, chemistry

AnotherDepArtifact déclarant htmlcleaner, google-api, tika

ThirdDepArtifact spring, httpclient, selenium déclarant

Il est un énorme gâchis, je ne sais pas si je l'utilise <dependencyManagement> correctement, il semble être seulement utile pour la gestion des versions de dépendance.

Je pensais à adapter mon développement d'applications pour « la conception maven multimodule ». Mais si vous voulez créer des services de printemps / haricots, qui vient d'utiliser différentes bibliothèques, dans un module, vous ne les mettez pas en œuvre dans différents modules, simplement parce qu'ils utilisent bibliothèque autre module utilise également: -)

Answer 1

Maven 3.1 devrait résoudre ce problème en introduisant "mixins". En attendant, il semble que je peux obtenir la plupart des fonctionnalités nécessaires à la bonne utilisation des profils, comme je l'ai décrit dans ce billet de blog:

http: // weblogs.java.net/blog/fabriziogiudici/archive/2011/07/19/maven-pom-composition-means-profiles

S'il vous plaît laissez-moi savoir si vous le trouvez utile.

Answer 2

Je sais que vous avez dit qu'il pourrait être un cauchemar, mais je me sens fortement entre l'héritage de vos parents pom est le chemin à parcourir.

Je décris une bonne structure de projet multi-module cette réponse . Il décrit également l'utilisation d'un aggrégateur et l'héritage-enchaînant parents.

Certaines choses qui vous aideront à garder les choses organisées et sain d'esprit ...

• Utiliser les conventions de nommage; bonne ne sont pas seulement appeler les projets parents parent1 et parent2. Les noms d'utilisation qui décrivent ce genre de dépendances et d'autres choses configurent il est donc intuitive que les gens sachent qui à utiliser quand.
• Utilisez la fonction release / deploy Maven afin que ceux-ci sont dans votre repo versionné correctement et référence toujours des artefacts version fixe. Ne pas utiliser Snapshots est la première étape d'avoir déterministe, builds reproductible. problèmes débuggage les choses changent à la volée est très difficile.
• Ne comptez pas sur un fichier pom.xml pour savoir quelles dépendances vos besoins du projet. Cela vous mènera à éviter l'héritage et d'autres choses comme des profils personnalisés. Vous devez utiliser le maven-plugin-dépendance pour effectuer ces tâches d'analyse. Il y a des commandes comme mvn dependency:tree qui vous montre toutes les dépendances d'un projet et mvn dependency:analyze qui vous montre les dépendances inutilisées.

Si tout va bien, avec ce conseil, l'héritage de fichier POM parent ne semblera pas si compliqué et cauchemardesque. Bonne chance!

Answer 3

Si son principalement sur la version (numéro) contrôle - pourquoi ne pas préciser que la version de la dépendance en tant que propriété dans le projet parent et l'utiliser dans les projets enfants, comme

Parent

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>foo.bar</groupId>
    <artifactId>maven-parent</artifactId>
    <version>0.0.1</version>
    <packaging>pom</packaging>

    <properties>
        <log4j.version>1.2.16</log4j.version>
    </properties>

</project>

Enfant

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <artifactId>maven-parent</artifactId>
        <groupId>foo.bar</groupId>
        <version>0.0.1</version>
    </parent>

    <groupId>foo.bar</groupId>
    <artifactId>maven-child</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>${log4j.version}</version>
        </dependency>
    </dependencies>

</project>

Ceci est une solution simple qui vous permettent de spécifier des dépendances spécifiques du projet avec les numéros de version cohérente.