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

Johannes Schindelin schindelin at wisc.edu
Sat Mar 29 12:24:48 CDT 2014

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

> 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.


More information about the ImageJ-devel mailing list