web-dev-qa-db-fra.com

Le pot d'emballage n'est pas valide Le projet d'agrégateur a besoin d'un pom comme emballage

Mon projet comporte différents modules.

  • Chaque module a un pom.xml qui spécifie le conditionnement des pots.
  • Chaque pom fait référence au parent commun.
  • Dans le module parent, il y a aussi un pom.xml qui inclut tous les modules.

Lorsque j'ai essayé d'empaqueter en utilisant le pom.xml du module parent, il montre l'erreur - "Le pot d'emballage est un projet d'agrégateur non valide qui a besoin de pom comme emballage".

Que puis-je faire pour créer un fichier exécutable de l'application à partir de maven?

javamavenjarjavafx
32
Anvay

Pour faire court: si votre projet parent-agrégateur ne contient pas de code source (et c'est une bonne pratique), ajoutez simplement ceci à votre parent pom.xml:

<packaging>pom</packaging>

Si le projet parent contient du code source, je vous suggère fortement de:

  • déplacer ce code dans un nouveau module (appelons-le commons)
  • faire de commons un module enfant de votre projet parent
  • ajouter le module commons en tant que dépendance de tous les autres modules le nécessitant (peut-être tous)
  • ajouter <packaging>pom</packaging> dans le parent pom.xml
45
ben75

Maven requiert que le parent soit de packagingpom.

Vous pouvez faire en sorte qu'un projet pom se comporte comme s'il s'agissait d'un projet jar, en incluant un tas d'exécutions de plug-in et en les attachant à leur phase de cycle de vie suivante. Ce n'est pas une route heureuse. Au contraire, ce qui suit est .

D'un point de vue orienté objet, que voulez-vous? Vous avez un objet qui est composé d'un tas d'autres objets, non? En d'autres termes composition , par opposition à l'héritage.

Votre livraison finale est composée des autres projets (jar), c'est-à-dire que les autres projets sont des dépendances du projet de livraison finale. Vous définirez les autres projets chacun comme dependency afin que quiconque utilise votre livraison finale sache quelles dépendances (transitives) obtenir. Alternativement, la livraison finale jar pourrait être présentée sous la forme "uber -jar" et contenir ainsi toutes ses dépendances. Tout dépend vraiment de la façon dont la livraison finale doit être utilisée.

Dans le même temps, les deux aspects suivants peuvent (peuvent) exister:

  • Le projet parent (qui est différent du projet de livraison final, en fait il peut également être le parent du projet de livraison final) définit les points communs entre ses enfants ultérieurs, comme c'est ce que vous devez attendre de l'héritage. Un enfant est un projet qui fait référence au parent via la configuration parent dans son POM.
  • Un projet qui définit modules qui doit être facilement construit en une seule fois. Les modules sont des projets référencés par l'utilisation de modules.module. C'est généralement (je suppose> 99%) fait dans le projet parent, mais pas nécessairement. Vous pouvez également le mettre dans le projet de livraison final (sans affecter l'héritage, car c'est donc une bête différente), mais c'est atypique et je n'irais pas là-bas.
14
Sander Verhagen