Re: SciJava-style plugin discovery

24 views
Skip to first unread message

Curtis Rueden

unread,
Aug 19, 2015, 12:56:18 PM8/19/15
to Chris Weisiger, Mark Tsuchida, SciJava
Hi Chris,

CCing SciJava mailing list.

> We can use the org.scijava.plugin.Plugin annotation fine, and see the
> META-INF/json entries get generated when building. Is there an example
> somewhere of how we'd go about making use of those entries to perform
> plugin discovery?

Use the PluginService:

  final Context context = new Context();
  final PluginService pluginService = context.service(PluginService.class);
  final List<PluginInfo<MicroManagerDriver>> driverPlugins = pluginService.getPluginsOfType(MicroManagerDriver.class);
  final List<MicroManagerDriver> drivers = pluginService.createInstancesOfType(MicroManagerDriver.class);

If MicroManagerDriver extends SingletonPlugin (e.g., is a HandlerPlugin), you can make a MicroManagerDriverService which manages the singletons. Model it after an existing core service such as the ConsoleService/DefaultConsoleService.

See also this tutorial:

Happy to go into further detail on these patterns as needed.

Regards,
Curtis

On Tue, Aug 18, 2015 at 4:46 PM, Chris Weisiger <cwei...@msg.ucsf.edu> wrote:
Hi Curtis,

I'm working on µManager 2.0, and one of the things we'd like to add is SciJava-style plugins, where the developer just has to annotate their plugin class and the plugin is "magically" discovered by the main program and made available to the user.

We can use the org.scijava.plugin.Plugin annotation fine, and see the META-INF/json entries get generated when building. Is there an example somewhere of how we'd go about making use of those entries to perform plugin discovery?

Thanks!

-Chris

Curtis Rueden

unread,
Aug 19, 2015, 1:43:54 PM8/19/15
to Chris Weisiger, Mark Tsuchida, SciJava
Hi Chris,

> Is it assumed that all plugin jars are already on the classpath?

Normally, yes. The SciJava plugin discovery works via class loaders.

> Is there some facility for limiting the search space to a specific
> directory?

You can pass your own ClassLoader which limits resource discovery however you wish:

  PluginFinder pluginFinder = new DefaultPluginFinder(myClassLoader);
  PluginIndex pluginIndex = new PluginIndex(pluginFinder);
  Context context = new Context(pluginIndex);

Since you interface with ImageJ, though—I would highly recommend piggybacking off the existing Context, rather than spinning up your own. There are a few ways of doing that...

Not-ideal but tolerated IJ1-specific way:
  Context context = (Context) IJ.runPlugIn("org.scijava.Context", "");

Better way is to pass the context object around wherever you need it, to avoid any static method calls, etc. This maintains the encapsulation of each application context. If you use parameterized SciJava commands and scripts, you can declare the context and its services as @Parameter inputs, which get autofilled by the framework.

Even nicer, you can declare singleton plugins as inputs too, and the user will be prompted to make a choice. For example: "@Parameter Codec codec;" and the user will see a drop-down box with a list of codecs to choose from. Of course, whether this scenario applies to your use case depends on the role of your new type of plugin.

Regards,
Curtis


On Wed, Aug 19, 2015 at 12:15 PM, Chris Weisiger <cwei...@msg.ucsf.edu> wrote:
Thanks, Curtis,

On Wed, Aug 19, 2015 at 9:55 AM, Curtis Rueden <ctru...@wisc.edu> wrote:
Hi Chris

Use the PluginService:

  final Context context = new Context();
  final PluginService pluginService = context.service(PluginService.class);
  final List<PluginInfo<MicroManagerDriver>> driverPlugins = pluginService.getPluginsOfType(MicroManagerDriver.class);
  final List<MicroManagerDriver> drivers = pluginService.createInstancesOfType(MicroManagerDriver.class);

If MicroManagerDriver extends SingletonPlugin (e.g., is a HandlerPlugin), you can make a MicroManagerDriverService which manages the singletons. Model it after an existing core service such as the ConsoleService/DefaultConsoleService.

I note that this example does not provide any context for where the plugin jars may be found. Is it assumed that all plugin jars are already on the classpath? Is there some facility for limiting the search space to a specific directory?

-Chris


Reply all
Reply to author
Forward
0 new messages