<div dir="ltr">Hi all,<div><br></div><div>To follow up on this old thread:</div><div><br></div><div><div>> "What is SciJava, and what is ImageJ?"</div><div><div>></div><div>> The intuition that appeals to me is: if it is image-specific, it is</div>
<div>> part of ImageJ. And if it is more general, it lives in SciJava.</div></div><div><br></div><div>Earlier this week, we completed a refactoring of the ImageJ2 component structure in line with this intuition:</div>
<div>
<br></div><div>* <a href="https://github.com/imagej">https://github.com/imagej</a> -- contains components specific to image processing.</div><div>* <a href="https://github.com/scijava">https://github.com/scijava</a> -- contains foundation components which are *not* specific to images.</div>
<div><br></div><div>Each component lives in its own Git repository as a single-module Maven project, with release version couplings to other components.</div><div><br></div><div>The ImageJ2 application is now made up of the following core components:<br>
</div><div><br></div><div>* imagej-common -- the core ImageJ library and data model built on ImgLib2</div><div>* imagej-ops -- the framework for extensible image processing algorithms announced earlier this month</div><div>
* imagej-updater -- the famous ImageJ Updater which keeps people up-to-date<br></div><div>* imagej-launcher -- the command line executable for launching ImageJ</div><div><div>* imagej-legacy -- the glue component providing backwards compatibility with ImageJ 1.x</div>
</div><div>* scijava-common -- the core library for non-image-processing-specific logic, including the plugin mechanism, application container, and module framework</div><div><br></div><div>ImageJ2 also includes the following optional plugin components:<br>
</div><div><br></div><div>* imagej-plugins-commands -- built-in commands (i.e., most of the ImageJ menu structure)</div><div>* imagej-plugins-tools -- built-in tools (i.e., the toolbar buttons)</div><div>* imagej-plugins-uploader-* -- plugins for the ImageJ Updater which make it possible to upload to ImageJ update sites</div>
<div>* imagej-ui-swing -- the "modern" ImageJ2 user interface</div><div>* scijava-plugins-platforms -- platform-specific logic (stuff like "how do I open a web browser on OS X?")</div><div>* scijava-plugins-text-* -- plugins for rendering text formats like Markdown</div>
<div>* scripting-* -- plugins for the various scripting languages: Beanshell, Clojure, etc.<br></div><div><br></div><div>More details at:</div><div><a href="http://jenkins.imagej.net/job/ImageJ-daily/lastSuccessfulBuild/artifact/target/site/dependencies.html">http://jenkins.imagej.net/job/ImageJ-daily/lastSuccessfulBuild/artifact/target/site/dependencies.html</a><br>
</div><div><br></div><div>Lastly, a couple of comments relating to earlier messages in this thread:</div><div><br></div><div>* We decided not to split imagej-ops in half.</div><div>* The ij-core module and scripting code was thus migrated to scijava-common.</div>
<div><br></div><div>We aim to release a new ImageJ2 beta by the end of this week.</div></div><div><br></div><div>Regards,</div><div>Curtis</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 29, 2014 at 12:24 PM, Johannes Schindelin <span dir="ltr"><<a href="mailto:schindelin@wisc.edu" target="_blank">schindelin@wisc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Curtis,<br>
<div class=""><br>
On Sat, 29 Mar 2014, Curtis Rueden wrote:<br>
<br>
> * scijava-ops -> scijava-ops-OLD (or moved to "old-master" topic branch)<br>
> -- preserve previous effort until all code has been successfully<br>
> migrated out<br>
<br>
</div>I would like to do that anyway.<br>
<div class=""><br>
> * imagej-ops core framework -> scijava-ops<br>
> -- the core framework is not image specific<br>
<br>
</div>How about doing that later? There is no need to stress ourselves out about<br>
it; we can easily do that anytime.<br>
<div class=""><br>
> * ij-core module framework -> migrate into scijava-ops<br>
> -- that framework includes modules, commands, displays and widgets<br>
> -- Christian asked me: why not move ij-core's module framework into<br>
> scijava-common?<br>
> -- I strongly considered that, but instead I think it fits perfectly into<br>
> the OPS framework<br>
<br>
</div>I agree, but I would suggest doing that later, too.<br>
<div class=""><br>
> * imagej-ops image processing ops -> stay in imagej-ops<br>
> -- these ops are image-specific, and depend on ImgLib2<br>
<br>
</div>That makes absolute sense (as the above), but I would like to focus on<br>
using ij-ops first. Traditionally, it has been much easier to develop a<br>
fast-moving project when it is maintained in a single repository.<br>
<div class=""><br>
> * imagej-ops widgets -> stay in imagej-ops<br>
> -- and move Swing-specific code into ij-ui-swing<br>
<br>
</div>I guess that probably needs to happen sooner rather than later because the<br>
technical debt incurred by mixing UI with processing can be a huge pain in<br>
the back side.<br>
<div class=""><br>
> * ij-core scripting framework -> scijava-scripting<br>
> -- scripting support is not image-specific<br>
><br>
> * ij-scripting-* -> scijava-scripting-*<br>
> -- each of these has different, often very large, dependencies<br>
<br>
</div>I agree that this is a good plan, but again, I would love to see this<br>
happening later. Preferably after switching Fiji to the ImageJ2 script<br>
editor because I see a couple of architectural questions looming for us;<br>
These architectural issues are much easier solved when all involved code<br>
lives in the same repository.<br>
<div class=""><br>
> * other ij-core unrelated stuff -> think more; consider case-by-case<br>
> -- maybe some goes to scijava-common...<br>
> -- would be nice if the "ij-core" module could completely go away<br>
<br>
</div>Whoa. Radical food for thought. But I begin to see your reasoning and to<br>
agree.<br>
<div class=""><br>
> I know that such changes would rock the boat... again. But before we get<br>
> too much farther along I would like to have a very clear, sensible policy<br>
> which answers the question: "What is SciJava, and what is ImageJ?" And I<br>
> think the structure above would do that, and be a really strong foundation<br>
> for the next decade at least.<br>
<br>
</div>Makes sense. How about revisiting the split in two weeks? We could even<br>
call it milestone 0.2.0.<br>
<br>
Ciao,<br>
Dscho<br>
</blockquote></div><br></div>