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 <schinde...@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 >
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
