Comme nous l'avons vu, l'erreur est le résultat de votre plugin ne pas trouver votre bibliothèque API. Dans la plupart des cas, je vous recommande d'inclure cette dépendance dans le fichier JAR de votre plugin.
Cependant, si cette API, qui n'est pas elle-même un plugin, est utilisée par plusieurs plugins, créez un répertoire lib à la racine du serveur et placez-y votre JAR API. Tous les fichiers JAR situés dans ce répertoire seront chargés par Bukkit/Spigot et disponibles pour tous les plugins.
Edit:
Comme je l'ai mentionné dans mon commentaire, je l'ai utilisé cette technique depuis si longtemps, je suppose qu'il soit une caractéristique de Bukkit. Hélas, ce n'est pas le cas.
Ajout Classpath dans MANIFEST.MF
Ajout de la configuration maven-jar-plugin suivante à votre POM, assure que toutes les dépendances ayant une portée de compile sera ajouté au classpath de votre plugin. Le chemin de classe est relatif à l'emplacement de votre plugin (le répertoire plugin), donc ../lib/ est le répertoire lib dans la racine du serveur.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.6</version>
<configuration>
<archive>
<manifestEntries>
<Built-By>You</Built-By>
</manifestEntries>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>../lib/</classpathPrefix>
</manifest>
</archive>
/configuration>
</plugin>
Essentiellement, cela crée une entrée dans META-INF/MANIFEST.MF de votre plugin le référencement de votre bibliothèque API similaire à ce qui suit:
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Built-By: You
Class-Path: ../lib/my-api.jar
Created-By: Apache Maven 3.3.9
Build-Jdk: 1.8.0_73
Créer un Uber-JAR
La solution ci-dessus a travaillé bien pour nous, fournissant un emplacement unique pour la maintenance des bibliothèques utilisées par plusieurs de nos plugins internes. Là encore, nous gérons notre propre serveur.
Si vos plans à long terme sont de publier votre plugin pour d'autres à utiliser, cette solution n'est pas idéale. Bien que cela fonctionne, cela nécessite un travail supplémentaire de la part des opérateurs de serveur, sauf si l'installation de votre bibliothèque d'API est automatisée. Là encore, l'installation de fichiers autres que ceux attendus par les opérateurs de serveurs n'est peut-être pas une bonne idée non plus.
Une meilleure solution consiste à créer un fichier UBER-JAR qui inclut votre code et toutes les dépendances uniques, telles que votre API. Cela élimine le besoin d'installer votre JAR API comme dans l'exemple ci-dessus. Plus important encore, il évite les incompatibilités potentielles des versions à mesure que de nouvelles versions de votre plugin sont publiées. En ajoutant la configuration maven-shade-plugin suivante à votre POM, vous créerez un uber-JAR qui inclut vos classes de plug-in et d'API et les interfaces dans un seul fichier JAR. L'exemple suppose que la votre API a Maven coordonnées me.andy:myapi:1.0
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<minimizeJar>true</minimizeJar>
<filters>
<filter>
<artifact>me.andy:myapi:1.0</artifact>
<includes>
<include>**</include>
</includes>
</filter>
</filters>
</configuration>
</execution>
</executions>
</plugin>
Après avoir exécuté mvn install, vous trouverez trois fichiers JAR dans le répertoire target (les noms de fichiers sont évidemment différentes):
original-myplugin-1.0.jar - l'original JAR comme il aurait été créé normalement.myplugin-1.0-shaded.jar - le JAR combinémyplugin-1.0.jar - le fichier JAR combiné avec des dépendances réduites. C'est le dernier plugin JAR.
Vous pouvez vérifier ce qui était inclus avec n'importe quel outil ZIP populaire.
Il s'agit d'une erreur d'exécution et non d'une erreur de compilation. –
@ElliottFrisch savez-vous comment je peux résoudre ce problème? –
Modifiez votre chemin de classe d'exécution. –