[ImageJ-devel] Fwd: SciJava Common plugin framework

[Curtis Rueden]

Hi all,

For those not on the scijava mailing list (see http://www.scijava.org/ for
details), we have recently improved the ImageJ2 plugin framework to be more
general, rebranding it the SciJava Common plugin framework.

As some of you already know, SciJava is an umbrella effort to unify efforts
across several different software projects, including ImageJ2, Fiji,
ImgLib2, Bio-Formats, SCIFIO, OMERO, CellProfiler, KNIME, Icy and more. The
primary goal is to share code as much as is practical, and have common
standards (e.g, for regions of interests) even when it is not.

The SciJava Common framework gives us a very small, common place to put
shared functionality across these projects. For example, the improved
plugin framework means that ImageJ2 plugins (e.g., commands) and SCIFIO
plugins (e.g., file format readers) are now two flavors of the same
kool-aid.

See below for further details.

Regards,
Curtis


---------- Forwarded message ----------
From: Curtis Rueden <ctrueden at wisc.edu>
Date: Tue, Feb 19, 2013 at 11:22 AM
Subject: SciJava Common plugin framework
To: SciJava <scijava at googlegroups.com>


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,
Curtis

[1] https://github.com/scijava/scijava-common
[2] http://trac.imagej.net/ticket/9
[3] http://sezpoz.java.net/
[4] http://eventbus.org/

P.S. Did you know sloccount has concurrency issues?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20130225/2630e63e/attachment.html>