SciJava Common plugin framework

21 views

Skip to first unread message

Curtis Rueden

unread,

Feb 19, 2013, 12:22:39 PM2/19/13

to SciJava

Hi everyone,

In the past few days, I factored out the ImageJ2 plugin framework from ImageJ2 core, migrating it into SciJava Common [1].

SciJava Common now provides a plugin framework, with an extensible mechanism for service discovery, driven by the SezPoz library, so that plugins can be loaded dynamically. We have already updated ImageJ2 to use it, and are in the process of refactoring SCIFIO to use it as well.

SCIFIO and ImageJ2 were both using SezPoz for extensibility/discovery, and had each invented their own simple application contexts to support this. Using a common library greatly improves DRYness, and truly cements SCIFIO as *the* driving I/O library for ImageJ2 and ImgLib2 [2].

In short, we figured: with ImageJ2 and SCIFIO being developed in the same office, and both of them part of this common SciJava effort, there really was no excuse not to reuse code between them.

In addition, we have been desiring a way to add extensibility features to ImgLib2, without creating a circular dependency on ImageJ2, and this will now be possible. That is, parts of ImgLib2 could now depend on SciJava Common if they wish to provide new types of plugins (e.g., OPS functions) with automatic discovery.

This refactoring also migrates the ImageJ event subsystem into SciJava Common, meaning that anything using SciJava Common now gets a pub/sub style event system for free. (This will also be useful for SCIFIO/Bio-Formats and ImgLib2, since a long-standing issue has been better hooks into ongoing operations.)

SciJava Common has two dependencies, SezPoz [3] and EventBus [4], both of which are completely encapsulated such that downstream code does not directly depend on either library. So in the future, we could theoretically switch to a different discovery mechanism or event library with no downstream code changes.

Still to do: improve SciJava Common's logging implementation. We have an SLF4J-based LogService (as well as a stderr-based one, for simplicity), but it needs to work in a more granular way, with a separate logger for each calling class, similar to how Bio-Formats works now. But I want to avoid the need to manually configure a logger in downstream code; it should rather "just work". This will give more flexibility when configuring logging.

Lastly, just for fun, some SLOC counts (Java only) as of today:

SciJava Common: 8K

ImgLib1: 37K

ImageJ2: 75K

ImageJ1: 96K

ImgLib2: 101K

OMERO: 392K [all components, Java only]

Fiji: 506K [no submodules]

Bio-Formats: 584K [develop branch]

SCIFIO: 619K [hinerm/scifio-wrappers branch]

And remember, kids: every line of code is a liability!

Regards,