Dans un projet maven multi-modules, puis-je créer un module pour calculer les dépendances transitives basées sur le DependencyReducedPom d'un autre module?

Question

Cela semble être une question simple mais j'ai trouvé cela difficile en raison du paradigme extrêmement rigoureux des cycles de vie et des phases de Maven :

En supposant que dans un projet Maven multi-modules, plusieurs plugins sont utilisés dans différentes phases pour réécrire le fichier pom.xml en versions plus efficaces, les exemples notables sont :

• maven-shade-plugin (si est activé) : lorsque le uber-jar ombré doit être publié, le plugin peut éliminer les dépendances qui n'ont pas besoin d'être incluses. Toujours exécuté dans la phase de package.

• flatten-maven-plugin : permet au pom.xml publié du module de ne plus dépendre du pom parent, en remplaçant les références de propriétés par leurs valeurs réelles. Peut être exécuté à n'importe quelle phase, mais pour maintenir l'interopérabilité avec maven-shade-plugin, il est également limité à la phase de package (voir https://issues.apache.org/jira/browse/MSHADE-323)

Lorsqu'ils sont combinés avec d'autres modules, il semble que le moteur de construction maven reactor se débat fréquemment avec la version du pom réécrit à utiliser pour calculer la dépendance transitive. Idéalement, la version finale après la phase de package devrait être utilisée. Mais dans la dernière version de Maven (3.6.3), il est uniquement capable d'utiliser le pom.xml AVANT les deux réécritures, sans dépendances réduites et toutes les propriétés non remplacées correctement.

Mes questions sont :

1. Quel est l'intérêt de cette conception ? Pourquoi utiliser un pom.xml incomplet lorsque tous les plugins le remplacent explicitement ?

2. Comment remplacer ce comportement de sorte que la version finale du pom.xml soit toujours générée et utilisée, indépendamment de l'objectif Maven demandé ?

MISE À JOUR 1 : Pour le moment, j'utilise une simple contournement en :

• divisant le premier module en un projet Maven indépendant, avec à la fois maven-shade et flatten-maven plugin invoqués à la phase de package. (Je n'ai pas de preuve directe mais je soupçonne que c'est ainsi que les dépendances reconditionnées comme spark-project.hive https://mvnrepository.com/artifact/org.spark-project.hive/hive-common ont été faites, voir https://issues.apache.org/jira/browse/SPARK-20202 pour une discussion pertinente)

• utiliser un script shell pour compiler/publier le projet ci-dessus et le projet multi-modules principal séquentiellement.

Je ne suis pas un grand fan des scripts shell, et je pense que cela trahit la prouesse agnostique de la plate-forme que la communauté JVM chérit. Donc si vous avez une meilleure solution, veuillez la poster ici et je l'accepterai en fonction de sa popularité.

Merci beaucoup pour votre avis

Answer 1

La première chose est : le paradigme extrêmement rigoureux de Maven en termes de cycles de vie et de phases : ces cycles de vie et phases ont des raisons très valables.

De plus, vous avez mentionné que plusieurs plugins réécrivent le fichier pom.xml. Les seuls exemples sont maven-shade-plugin et flatten-maven-plugin comme vous l'avez mentionné.

En dehors de cela comme vous l'avez mentionné l'intention du plugin maven-shade-plugin :

Ce plugin permet d'emballer l'artifact dans un uber-jar, y compris ses dépendances et de "shader" - autrement dit, de renommer - les packages de certaines des dépendances.

L'intention est de "shader" les dépendances (décompiler les jars et les re-emballer dans un seul jar) et de créer un jar exécutable (ce qui peut également être fait avec le maven-assembly-plugin)... pas de se débarrasser des dépendances.

L'idée du plugin flatten-maven-plugin est de supprimer les parties d'un fichier pom qui ne sont pas nécessaires pour une utilisation ultérieure (Build POM vs. Consumer POM). Actuellement, cette partie fera partie du Core de Maven avec la version 3.7.0... C'est un grand premier pas pour séparer le pom de build et le pom de consommation.

Passons maintenant à la pointe du moteur de génération de réacteur qui est conçu pour définir l'ordre de construction en fonction des dépendances.

Idéalement, la version finale après la phase de package devrait être utilisée

Cela signifierait d'avoir des ordres et des dépendances différents (y compris les dépendances transitives) entre les phases avant le package et après le package (pour chaque exécution de ce type de plugin). Cela se traduirait par des résultats non reproductibles. En dehors de la nécessité de recalculer tout l'arbre des dépendances, etc.

Mais dans la dernière version de Maven (3.6.3), il est seulement capable d'utiliser le pom.xml AVANT les deux réécritures, sans réduire les dépendances & toutes les propriétés non remplacées correctement.

C'est également vrai pour toutes les versions précédentes. De plus, le pom.xml est lu au tout début de la construction...

Quel est l'intérêt de cette conception ? Pourquoi utiliser un pom.xml bâclé alors que tous les plugins le remplaçaient explicitement ?

Que voudriez-vous savoir exactement ? Vous avez également mentionné seulement deux plugins (et pas tous les plugins) avec des intentions différentes.

Comment outrepasser ce comportement de sorte que la version finale du pom.xml soit toujours générée et utilisée, indépendamment de l'objectif Maven demandé ?

Il n'y a pas d'option pour outrepasser ce comportement car elle n'existe pas. Cela signifierait réécrire de grandes parties du Core de Maven.