Mavenization and debugging in Eclipse

johnkoestel · June 7, 2016, 9:48am

Hej everybody,

This is my first post in the ImageJ forum but I am not a newbie in programming ImageJ plugins in Java anymore. I have started a plugin collection for the semi-automized image-analyses of X-ray images of soil-columns in 2013 (christened to ‘soilj’). Since then, the project has been maturing to the point that I am seriously starting to think about publishing it.

I am aiming at including the project into the Fiji bundle and have been trying to re-model it according to the Fiji requirements. However, this lead to a three day trip to a mavenized ImageJ hell and back. Since I am not eager to repeat this experience anytime soon, I thought it may be time to ask you for some advice.

So here is what happened. I am using Eclipse and had been setting it up following Patrick Pirotte’s cookbook “The ImageJ Eclipse Howto”:
http://imagejdocu.tudor.lu/doku.php?id=howto:plugins:the_imagej_eclipse_howto

Until last Friday, this had been working out fine. I had still been using a relatively old ImageJ version (I think some 1.47). I could write my plugins, run IJ as an application in Eclipse and the plugins would appear in the IJ plugin folder. I also could debug the whole thing in Eclipse, i.e. setting breakpoints for monitoring variable values, etc.

However, last Friday I was thinking it was time to upgrade to a new ImageJ version (1.50g) and try mavenizing my plugin at the same time. After two days of reading the Fiji.sc tutorials and trial and error I succeeded to set up Eclipse with mavenized versions of both imagej/fiji (I had tried them both) and soilj/soilj_ (I had also tried whether the underscore is still needed or not). The resulting soilj_.jar file was working fine when I copied it to the plugins folder of my regular Fiji, i.e. not the one in Eclipse.

I also managed to run the mavenized ImageJ and Fiji in Eclipse, even together with soilj. But what I never have managed was running my mavenized versions in Eclipse so that soilj was visible in the IJ/Fiji plugins folder. In other words, I did not succeed to set the whole thing up for debugging.

I have now several questions:

i) Has there been a change between IJ 1.47 and IJ 1.50 concerning the prerequisites that IJ-plugins are visible in IJ when running in Eclipse? I have found out that I now need to edit the IJ_Props.txt file according to my plugin names in order to have them appearing in IJ instances under Eclipse. Before last Friday, the soilj plugins would appear in my Eclipse-IJ without me having edited IJ_Props.txt.

ii) Is it possible to achieve the same thing with mavenized versions? I have not succeeded to do so but may have overlooked some spurious refactoring between alternative soilj spellings (SoilJ/SoilJ_/soilj/soil_) and necessary entries in config files (IJ_Props/plugins.config). If you tell me now that it should not be a problem, I will try again. But maybe it is a problem?

iii) Are the underscores still needed for IJ-plugins to be visible in IJ or Fiji?

iv) Would you recommend making soilj a Fiji or rather an ImageJ plugin? I am really confused about what difference it would make. I am normally using the Fijified ImageJ, so I had thought I should make it a Fiji plugin. Maybe there is some documentation about this that I did not find?

v) Would you recommend migrating soilj to imagej2 before making it public?

OK… I guess that’s enough stupid questions for today… : )

Apologies for the longish post and cheers from sunny Sweden,

/John

ctrueden · March 4, 2016, 2:32pm

Welcome to the forum, @johnkoestel!

Not that I know of. But you can rule out issues with ImageJ 1.x itself by setting the version of net.imagej:ij in your Maven POM. Try setting it to one of the available older versions.

Did you see the minimal-ij1-plugin example? Here is how it sets the plugins.dir property so that the plugin appears in the menus when launched from an IDE:

github.com

imagej/example-legacy-plugin/blob/780286866ee67ffdc6506217c3f25d9a0ac15f6d/src/main/java/Process_Pixels.java

/*
 * To the extent possible under law, the Fiji developers have waived
 * all copyright and related or neighboring rights to this tutorial code.
 *
 * See the CC0 1.0 Universal license for details:
 *     http://creativecommons.org/publicdomain/zero/1.0/
 */

import ij.IJ;
import ij.ImageJ;
import ij.ImagePlus;
import ij.gui.GenericDialog;
import ij.plugin.filter.PlugInFilter;
import ij.process.ImageProcessor;

/**
 * ProcessPixels
 *
 * A template for processing each pixel of either
 * GRAY8, GRAY16, GRAY32 or COLOR_RGB images.

This file has been truncated. show original

Underscores are needed if your plugin is an ImageJ 1.x style plugin. I.e.: does it implement ij.plugin.PlugIn or ij.plugin.filter.PlugInFilter? Then put an underscore in your JAR file and/or in your class name.

If you write an ImageJ2 command plugin (i.e.: implement the org.scijava.command.Command interface) then the underscore is no longer necessary.

I am not sure what you mean by “Fiji plugin” here. The term “Fiji” refers to a distribution of ImageJ2 that comes bundled with many additional plugins. There are no fundamental technical differences between a “Fiji” plugin and any other ImageJ plugin, since “Fiji is Just ImageJ”.

If you are asking whether to include your plugin with the Fiji distribution by meeting the Fiji contribution requirements, that is up to you. We are happy to support you in that effort, if you decide to go that route! Another possibility is to create your own update site for soilj, which would impose fewer restrictions on your development choices. See the Distribution page for a discussion of the various options.

No, keep it as ImageJ 1.x, since you have that working. There are certainly pieces that you could begin migrating to ImageJ2 any time—for example, if there are Ops which perform image processing tasks you need to do, or if you want to leverage the more powerful ImgLib2 data model—but in many cases there is no reason to fully switch right now. Some components of ImageJ2 are still under heavy development, and it makes sense to wait until the system is out of beta.

johnkoestel · March 7, 2016, 9:39am

Hej ctrueden,

Thanks a lot for the warm welcome and the very helpful answers.

OK. I had tried this already but it had not worked. I suspect I had gotten something else wrong at the same time. I have meanwhile found out how it works with the newest version.

Yes, I did, of course. I had built the mavenized version of my own plugin using the minimal plugin as a template. I had however missed to look into the code of the minimal plugin itself, assuming there would nothing new to be learnt there.
But this is cool news! I guess I will eventually mavenize my plugin for good.

OK. Thanks!

Well, yes, I was not sure myself. The question refers to a passage on http://fiji.sc/Writing_plugins.

OK. That’s good to hear. I already had been afraid IJ1.x would be abandoned in the near future.

Once more: Thanks a lot!

All the best from the North,

/John

mdoube · June 7, 2016, 9:48am

Since SoilJ has strong cross-over with BoneJ, may I suggest that you follow the developments in BoneJ2 by @rimadoma, and reuse the morphological libraries with your own soil science-specific wrapper plugins. Now seems like a good moment to migrate to ImageJ2, and we’d enjoy doing this together with you.

oburri · August 2, 2019, 6:12am

Hi all, I have a question regarding this side

github.com

imagej/example-legacy-plugin/blob/780286866ee67ffdc6506217c3f25d9a0ac15f6d/src/main/java/Process_Pixels.java#L176-L180


		// set the plugins.dir property to make the plugin appear in the Plugins menu
		Class<?> clazz = Process_Pixels.class;
		String url = clazz.getResource("/" + clazz.getName().replace('.', '/') + ".class").toString();
		String pluginsDir = url.substring(5, url.length() - clazz.getName().length() - 6);
		System.setProperty("plugins.dir", pluginsDir);

How do you manage to indicate where ImageJ should load some extra classes that the plugin is dependent on?

In my case, I’d like to use SVGDocument, which is in the org.w3c.dom package. But when I try to debug my code as in the minimal-ij1 case I get the following error:

So does anyone know how to make these external libraries accessible by ImageJ from within the Eclipse API?

Thanks a bunch!

ctrueden · July 1, 2016, 5:02pm

@oburri Why not just add them as dependencies to your POM? They will be on the classpath, and ImageJ should find them. No?

Note that the plugins.dir is only for ImageJ1 legacy compatibility; ImageJ2 tries to use the system classpath for as much as possible.

oburri · August 2, 2019, 6:12am

Hi @ctrueden

They are added as dependencies to the POM

However when I try to debug the plugin by running the main function, I get the error I mentionned above…

/**
 * Main method for debugging.
 * @param args unused
 */
public static void main(String[] args) {
	// set the plugins.dir property to make the plugin appear in the Plugins menu
	Class<?> clazz = SVG_ROI.class;
	String url = clazz.getResource("/" + clazz.getName().replace('.', '/') + ".class").toString();
	String pluginsDir = url.substring(5, url.length() - clazz.getName().length() - 6);
	System.setProperty("plugins.dir", pluginsDir);

	// start ImageJ
	new ImageJ();
}

ctrueden · July 7, 2016, 9:59am

Does it work if you use new net.imagej.ImageJ() rather than new ij.ImageJ()? (Or, if you don’t have net.imagej:imagej on your classpath, you can start up using new org.scijava.Context() instead.) You may also need to do ij.ui().showUI() (or context.service(UIService.class).showUI()).

The former is how ImageJ2 normally starts up, and it is closer to the “standard Java way” with system classpath. The latter is how plain ImageJ 1.x starts up, and it loads everything with its plugin classloader, which might have problems from an Eclipse context.

Sorry, I don’t have time to test this in more detail myself right now.