Galère de relocation maven
Je vous explique vite fait mon problème.
J'ai un gros projet maven, séparé en deux modules "API" et "Implémentation".
Le projet API contient quelques dépendances en mode "provided" : les annotations jetbrains, l'api paper...
Mais le projet API contient également des dépendances en mode "compile". Lors du build, ces dépendances sont incluses dans le JAR à l'aide du plugin maven shade mais en même temps elles sont relocated (= leur package est modifié).
Ça marche super, et lorsque je build mon projet Implementation qui dépend d'API les dépendances sont bien reconnues avec leur package relocated.
Maintenant, j'aimerais bien utilisé la fonctionnalité d'eclipse de "workspace resolution" : si je l'active, j'aurais le projet API en dépendance directe du projet Implémentation, et pas le JAR qui est build.
Ça permet de naviguer simplement entre les fichiers juste par un shift+click et d'avoir les changements en direct sans avoir à build l'API à chaque maj d'une signature de méthode.
Ça pourrait marcher super bien... mais les dépendances relocated foutent la merde : lorsque dans le projet Implementation j'essaye d'accéder à une dépendance de l'API qui est relocated, ça va utiliser son package avant relocation. Le problème est que, lors du build, le compilateur maven ne trouve pas les classes en question (évidemment, vu qu'elles ont été déplacées lors du build de l'API).
J'ai essayé quelques manips sans succès (genre copier aussi le code de relocation dans le pom.xml de l'Implementation), et je commence à désespérer.
Y a-t-il une solution pour pouvoir utiliser le workspace resolution avec des dépendances relocated ?
2 Replies
J'ai pensé à créer un module maven qui ne contient aucun code mais uniquement les dépendances à shade ainsi que les relocations.
Comme ça l'API ne contient plus ce code mais uniquement une dépendance vers le projet "dépendances". Idem pour l'Implementation.
Ça marcherait probablement, mais est-ce une solution élégante ou bien c'est carrément bad practice ? :noPlease:
Ah ouais un gros bordel x)
Malheureusement je connais que Gradle perso, et je m'y connais bien dans les trucs complexes comme ça en plus avec plusieurs modules x)