[ImageJ-devel] Module structure for OPS, and support for scripting

Curtis Rueden ctrueden at wisc.edu
Wed Apr 30 12:03:48 CDT 2014


Hi all,

To follow up on this old thread:

> "What is SciJava, and what is ImageJ?"
>
> The intuition that appeals to me is: if it is image-specific, it is
> part of ImageJ. And if it is more general, it lives in SciJava.

Earlier this week, we completed a refactoring of the ImageJ2 component
structure in line with this intuition:

* https://github.com/imagej -- contains components specific to image
processing.
* https://github.com/scijava -- contains foundation components which are
*not* specific to images.

Each component lives in its own Git repository as a single-module Maven
project, with release version couplings to other components.

The ImageJ2 application is now made up of the following core components:

* imagej-common -- the core ImageJ library and data model built on ImgLib2
* imagej-ops -- the framework for extensible image processing algorithms
announced earlier this month
* imagej-updater -- the famous ImageJ Updater which keeps people up-to-date
* imagej-launcher -- the command line executable for launching ImageJ
* imagej-legacy -- the glue component providing backwards compatibility
with ImageJ 1.x
* scijava-common -- the core library for non-image-processing-specific
logic, including the plugin mechanism, application container, and module
framework

ImageJ2 also includes the following optional plugin components:

* imagej-plugins-commands -- built-in commands (i.e., most of the ImageJ
menu structure)
* imagej-plugins-tools -- built-in tools (i.e., the toolbar buttons)
* imagej-plugins-uploader-* -- plugins for the ImageJ Updater which make it
possible to upload to ImageJ update sites
* imagej-ui-swing -- the "modern" ImageJ2 user interface
* scijava-plugins-platforms -- platform-specific logic (stuff like "how do
I open a web browser on OS X?")
* scijava-plugins-text-* -- plugins for rendering text formats like Markdown
* scripting-* -- plugins for the various scripting languages: Beanshell,
Clojure, etc.

More details at:
http://jenkins.imagej.net/job/ImageJ-daily/lastSuccessfulBuild/artifact/target/site/dependencies.html

Lastly, a couple of comments relating to earlier messages in this thread:

* We decided not to split imagej-ops in half.
* The ij-core module and scripting code was thus migrated to scijava-common.

We aim to release a new ImageJ2 beta by the end of this week.

Regards,
Curtis


On Sat, Mar 29, 2014 at 12:24 PM, Johannes Schindelin
<schindelin at wisc.edu>wrote:

> Hi Curtis,
>
> On Sat, 29 Mar 2014, Curtis Rueden wrote:
>
> > * scijava-ops -> scijava-ops-OLD (or moved to "old-master" topic branch)
> >   -- preserve previous effort until all code has been successfully
> >   migrated out
>
> I would like to do that anyway.
>
> > * imagej-ops core framework -> scijava-ops
> >   -- the core framework is not image specific
>
> How about doing that later? There is no need to stress ourselves out about
> it; we can easily do that anytime.
>
> > * ij-core module framework -> migrate into scijava-ops
> >   -- that framework includes modules, commands, displays and widgets
> >   -- Christian asked me: why not move ij-core's module framework into
> > scijava-common?
> >   -- I strongly considered that, but instead I think it fits perfectly
> into
> > the OPS framework
>
> I agree, but I would suggest doing that later, too.
>
> > * imagej-ops image processing ops -> stay in imagej-ops
> >   -- these ops are image-specific, and depend on ImgLib2
>
> That makes absolute sense (as the above), but I would like to focus on
> using ij-ops first. Traditionally, it has been much easier to develop a
> fast-moving project when it is maintained in a single repository.
>
> > * imagej-ops widgets -> stay in imagej-ops
> >   -- and move Swing-specific code into ij-ui-swing
>
> I guess that probably needs to happen sooner rather than later because the
> technical debt incurred by mixing UI with processing can be a huge pain in
> the back side.
>
> > * ij-core scripting framework -> scijava-scripting
> >   -- scripting support is not image-specific
> >
> > * ij-scripting-* -> scijava-scripting-*
> >   -- each of these has different, often very large, dependencies
>
> I agree that this is a good plan, but again, I would love to see this
> happening later. Preferably after switching Fiji to the ImageJ2 script
> editor because I see a couple of architectural questions looming for us;
> These architectural issues are much easier solved when all involved code
> lives in the same repository.
>
> > * other ij-core unrelated stuff -> think more; consider case-by-case
> >   -- maybe some goes to scijava-common...
> >   -- would be nice if the "ij-core" module could completely go away
>
> Whoa. Radical food for thought. But I begin to see your reasoning and to
> agree.
>
> > I know that such changes would rock the boat... again. But before we get
> > too much farther along I would like to have a very clear, sensible policy
> > which answers the question: "What is SciJava, and what is ImageJ?" And I
> > think the structure above would do that, and be a really strong
> foundation
> > for the next decade at least.
>
> Makes sense. How about revisiting the split in two weeks? We could even
> call it milestone 0.2.0.
>
> Ciao,
> Dscho
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20140430/ffebf1d7/attachment.html>


More information about the ImageJ-devel mailing list