Maven Abhängigkeit & Java Service Provider Schnittstelle

Question

Quick Hintergrund:
Ich habe eine Java Service Provider-Schnittstelle eingerichtet, damit Benutzer ihre eigenen benutzerdefinierten Plugins erstellen können. Die Schnittstelle, die sie implementieren, ist in einem eigenen eigenständigen Paket, so dass ich ihnen ein kleineres Paket ohne anderen sperrigen Code freigeben kann.

Sobald Benutzer ihre JAR erstellen, können sie sie während der Laufzeit dynamisch mit einigen Reflection-Hacks (die ich hier auf SO gefunden habe) in die Anwendung laden. Diese scheinen gut zu funktionieren, aber sobald ich auf einen anderen Entwickler-Rechner (und unsere Jenkins-Box) umgestiegen bin, werden die Abhängigkeiten irgendwie abgeworfen.

Das JAR für die Schnittstelle ist eine Abhängigkeit von der Hauptanwendung und den kleineren vom Benutzer erstellten Plugins. Wenn Benutzer die JAR hochladen, verwenden sie eine JAR, die diese Abhängigkeit enthält, die dazu beiträgt, dass die Schnittstelle identisch ist. Dies ermöglicht es dem Java SPI, es aufzunehmen und nutzbar zu machen. Ich habe angefangen, die Benutzerpakete zu wechseln, um die Abhängigkeit als <scope>provided</scope> in Hoffnungen zu verwenden, die org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.util.ServiceConfigurationError: com.company.interface.MyInterface: Provider com.usercode.ClassName not a subtype behebt.

Bei der Verwendung von bereitgestellten Bereich lief ich verschiedene Fehler von java.lang.NoClassDefFoundError: com/company/interface/MyInterface beim Versuch in Benutzergläser laden.

Wer weiß, was ich mit diesem Interface JAR und Maven machen könnte, damit diese zusammen nett spielen?

Answer 1

Wenn die Plugins provided scope für dieses jar verwenden, müssen Sie sicherstellen, dass die Hauptanwendung, die diese Plugins ausführt, dieses jar auf dem Klassenpfad bereitstellt, auf den die Plugins zugreifen können.

Auch dieser Fehler: java.lang.NoClassDefFoundError ist nicht die Ursache. Sie sollten die erste Instanz dieses Fehlers in den Anwendungsprotokollen finden, die die Grundursache dieses Fehlers anzeigen sollte. Wenn die Klasse im Klassenpfad fehlt, wird sie java.lang.ClassNotFoundException sein.