Mavenization and debugging in Eclipse

[johnkoestel]

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 (Curtis Rueden)]

Welcome to the forum, @johnkoestel!

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?

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.

Is it possible to achieve the same thing with mavenized 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:

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

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

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.

Would you recommend making soilj a Fiji or rather an ImageJ plugin?

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.

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

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]

Hej ctrueden,

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

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.

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.

Did you see the minimal-ij1-plugin example?

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.

Underscores are needed if your plugin is an ImageJ 1.x style plugin

OK. Thanks!

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

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

Update your POM
• Update your parent pom. This will dictate what dependency management is available to you. If you’re writing a core ImageJ plugin, then pom-imagej is appropriate. A Fiji plugin should use pom-fiji, however.
• Update pom version to latest: which depends on if your parent is pom-imagej or pom-fiji
• Update your groupId. ImageJ projects use a net.imagej groupId, while Fiji projects use sc.fiji—or you may use your own if you do not plan to distribute your plugin with the core ImageJ or Fiji projects.
• Update your artifactId to something appropriate based on the intended use of your project.
• Update your and to something appropriate for your new artifactId.

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.

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 (Michael Doube)]

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 (Olivier Burri)]

Hi all, I have a question regarding this side

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

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 (Curtis Rueden)]

@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 (Olivier Burri)]

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 (Curtis Rueden)]

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.