I'm currently migrating my application from JPF to pf4j and discovered a problem in the ExtensionAnnotationProcessor in combination with the ServiceProviderExtensionStorage.
I'm using the following pattern to define extension points and extensions:

In contrast to your examples there are abstract classes (MainMenuAdapter, BootAdapter) for each available extension point. The extensions are derived from these abstract classes instead of the extension point interfaces (MainMenuExtensionPoint, BootExtensionPoint). This gives a bit more flexibility, because later added methods in an extension point can be implemented in the abstract classes without the need of modifying the extension points in all plugins. From my experience in certain projects this is a quite common pattern - similar to the java.awt.event.WindowListener / java.awt.event.WindowAdapter approach in the Java classpath.
Basically this approach also works with pf4j. But the ExtensionAnnotationProcessor in combination with the ServiceProviderExtensionStorage doesn't behave as expected in this scenario. For the above scenario the following files are generated:
META-INF/services/com.example.api.BootAdapter
META-INF/services/com.example.api.MainMenuAdapter
Instead the ExtensionAnnotationProcessor should create these files:
META-INF/services/com.example.api.BootExtensionPoint
META-INF/services/com.example.api.MainMenuExtensionPoint
Because of this problem the PluginManager is not able to load the extensions by its interface via pluginManager.getExtensions(BootExtensionPoint.class). Instead I would have to call pluginManager.getExtensions(BootAdapter.class).
I'm going to propose a pull request with a possible workaround for this problem.
I'm currently migrating my application from JPF to pf4j and discovered a problem in the
ExtensionAnnotationProcessorin combination with theServiceProviderExtensionStorage.I'm using the following pattern to define extension points and extensions:
In contrast to your examples there are abstract classes (
MainMenuAdapter,BootAdapter) for each available extension point. The extensions are derived from these abstract classes instead of the extension point interfaces (MainMenuExtensionPoint,BootExtensionPoint). This gives a bit more flexibility, because later added methods in an extension point can be implemented in the abstract classes without the need of modifying the extension points in all plugins. From my experience in certain projects this is a quite common pattern - similar to thejava.awt.event.WindowListener/java.awt.event.WindowAdapterapproach in the Java classpath.Basically this approach also works with pf4j. But the
ExtensionAnnotationProcessorin combination with theServiceProviderExtensionStoragedoesn't behave as expected in this scenario. For the above scenario the following files are generated:Instead the
ExtensionAnnotationProcessorshould create these files:Because of this problem the
PluginManageris not able to load the extensions by its interface viapluginManager.getExtensions(BootExtensionPoint.class). Instead I would have to callpluginManager.getExtensions(BootAdapter.class).I'm going to propose a pull request with a possible workaround for this problem.