Comment puis-je faire dépendre un module Maven d'un autre?

OK, je pensée j'ai compris comment utiliser Maven...

J'ai un projet de master M qui a des sous-projets ABet C. C contient certaines fonctionnalités communes (interfaces principalement), qui est nécessaire pour A et B. Je peux courir mvn compile jar:jar à partir du répertoire racine du projet (le M répertoire) et d'obtenir des fichiers JAR A.jarB.jaret C.jar. (Les versions pour tous ces objets sont actuellement 2.0-SNAPSHOT.)

Le maître pom.xml fichier dans le M des listes de répertoire C en vertu de son <dependencyManagement> marque, de sorte que A et B peut faire référence à C simplement en incluant une référence, comme suit:

<dependency>
    <groupId>my.project</groupId>
    <artifactId>C</artifactId>
</dependency>

Donc bon. Je peux courir mvn compile à partir de la ligne de commande et tout fonctionne bien. Mais quand j'ai ouvert le projet dans NetBeans, il se plaint du problème: "Certains de dépendance des artefacts ne sont pas dans le référentiel local", et il affirme que l'artefact manquant est C. De la même manière à partir de la ligne de commande, si je change dans le A ou B répertoires et essayez d'exécuter mvn compile j'obtiens "Erreur: impossible de résoudre l'artefact."

J'imagine que je pourrai aller manuellement à l'endroit où mon C.jar a été construit et géré mvn install:install-filemais je préfère trouver une solution qui me permet de simplement travailler directement dans NetBeans (et/ou dans Eclipse à l'aide de m2eclipse).

Ce que je fais mal?

source d'informationauteur Daniel Pryden

  1. 23

    Maven s'appuie sur le concept de dépendances binaires et les résout par le référentiel local. En d'autres termes, vous devez installer les paquets dans votre référentiel local si vous avez des dépendances entre eux, de la compilation et de l'emballage code n'est pas assez. Et pour ce faire, vous devez exécuter install (qui installer le paquet dans le dépôt local, pour une utilisation en tant que dépendance dans d'autres projets à l'échelle locale).

    Côté remarque: vous ne devriez pas appeler mvn compile jar:jar mais préfèrent mvn package. Tout d'abord, l'exécution de la package phase de déclencher toutes les phases avant package (y compris compile) et package lui-même. Deuxièmement, l'exécution de package invoquera jar:jarou war:waretc en fonction de la <packaging> la valeur du projet (cochez la introduction au cycle de vie pour plus de détails sur ce sujet). C'est l'une des grandes forces de Maven: vous n'avez pas besoin de savoir si le projet est un POT, d'une GUERRE, d'un EJB, etc et exécutez le but de les emballer. Il suffit d'exécuter le normalisée package phase et Maven va faire le travail (à l'aide de la valeur par défaut objectifs de liaisons).

    Que c'est pour le Maven partie théorique. À l'intérieur de IDEs, les choses peuvent être légèrement différents pour rendre le travail avec Maven plus pratique. IDEs peut utiliser les dépendances d'un projet (c'est à dire les dépendances sur le code à l'intérieur de l'IDE) au lieu de dépendances binaires de sorte que les modifications apportées à un projet sont visibles dans d'autres modules sans avoir à exécuter mvn install. C'est le cas de l'Éclipse + M2Eclipse. Et cela s'applique aussi à NetBeans dans les conditions suivantes (voir Gestion De La Dépendance):

    Astuce: Si vous ouvrez un projet que d'autres
    les projets dépendent, l'icône dans d'autres
    les projets de modifications à un "projet maven"
    icône pour indiquer que l'IDE sait
    a propos du lien entre les projets.
    Cependant, un tel lien n'est
    établie lorsque l'id de groupe,
    artifactId et version tous les match
    la dépendance et de projet
    de la déclaration. Fréquentes
    le problème, c'est que vous modifiez une API
    signature dans votre projet de bibliothèque, mais
    l'application n'est pas ramasser.
    Il est souvent causé par le fait que l'
    l'application utilise une version plus ancienne
    de la bibliothèque de l'artefact. L'artefact
    icône peut vous aider à suivre ces
    problèmes.

  2. 6

    Vous avez besoin pour exécuter mvn install au lieu de mvn compile. Le install objectif copie le construit jar dans le dépôt local après la compilation et de l'emballage. Si vous ne lancez la compilation, il ne compiler les fichiers de classe dans le target répertoire et de ne pas les rendre disponibles à d'autres projets.

    Dans Eclipse, si vous importez un pom de plus haut niveau, il va importer les sous-projets distincts Eclipse projets et mettre en place les dépendances de projets liés à la puis configurer chaque projet du chemin de classe à dépendre des autres. Je ne suis pas familier avec Netbeans mais je suis assez sûr qu'il y est une certaine façon de faire la même chose.

  3. 3

    netbeans liens ensemble des projets par le référentiel local de contenu, de sorte mvn install est nécessaire dans la plupart des scénarios.

  4. 0

    Ce n'est pas vrai, l'exécution d'une de déployer fera tous les précédents setps...

    Veuillez hava un coup d'oeil à:

    http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html