Posted by
Olivier Burri on
Feb 14, 2018; 1:37pm
URL: http://imagej.273.s1.nabble.com/java-plugin-administration-advice-tp5020087p5020092.html
Dear Kenneth,
I'm pretty sure you've heard the recommendations to use either Gradle or Maven when developing your plugins, so I'll avoid that :)
In ImageJ/Fiji utility classes reside in the 'jars' folder. But they can be in the plugins folder too.
So in your scenario
Your VOL class would exist in a VOL.jar file in the 'jars' folder.
Then while you develop other plugins that depend on this guy, you would point your IDE (Eclipse?) to this VOL.jar. Same thing for ij.jar, instead of copying it into the project, you simply point to its location. (The Java Build Path in Eclipse and for your ANT file, it would be using the <classpath> tag, if I recall)
Update VOL.class, and you would update the VOL.jar. All your plugins would access the same VOL.class file this way.
The simplest thing to 'administer' this would be for you to have an update site that stores all these utility classes. That way, when a new user arrives, a prerequisite is to activate your update site. If using Fiji, your update site will be pre-selectable on any new installation as long as you filled the list of update sites at
http://imagej.net/List_of_update_sites
You can then give them the actual plugin as you normally did, but everyone has the same 'utility' classes, even if they do not use it.
I just wanted to point out that the idea of plugins, unless you want them to work as an independent Java Application which bundles its own copy of ImageJ, is to avoid repackaging the same things, and avoid these redundancies. I think you're going in the right direction with your new approach!
All the best, hope this helps
Oli
-----Original Message-----
From: ImageJ Interest Group [mailto:
[hidden email]] On Behalf Of Kenneth Sloan
Sent: Tuesday, February 13, 2018 5:11 PM
To:
[hidden email]
Subject: java plugin administration advice
I posted something similar a while ago and got no response. Trying again.
I'm in need of instruction on how to administer shared "utility" Java classes in the context of ImageJ (and FIJI). Any advice is welcome.
Our work revolves around the frequent creation of custom Java plugins. Lately, I have been writing about 1 major plugin per month. As you might expect, these tend to form "families" of similar (but definitely different) plugins. Usually, the family resemblence depends on handling specific file formats. For example, I have a class called "VOL.class" which I'll use as an example. VOL manages a particular proprietary file format, and this file format is used by many of our custom Java plugins. It changes infrequently, but recently went through a major revision (mostly adding features).
I updated "VOL" while writing a new Java plugin. When I ran the new plugin, it was obvious that it was using the old version of VOL at runtime. In order to cause it to use the new version, I un-installed the old plugins, propagated the changes, rebuilt the old plugins, and all was well. But, it's clear to me (now) that, at runtime, ImageJ is finding ONE specific instance of VOL and using it in all plugins.
Our method for distributing plugins is to create a .jar file which contains everything necessary and using "drag&drop" to install the .jar file. The intent is that these .jar files are independent (not everyone needs, or wants, all of the plugins).
So...the question is: how can I structure either my source code environment, or the .jar files, or...???
Our previous mindset was that the .jar file for a single plugin was completely independent of anything else.
One thought is to create separate .jar files for each shared class and install these (where?) separately. This would (slightly) increase the complexity of installing a new plugin (sometimes this is done by customers who are blindly following an installation procedure). Another is to change the names to avoid conflict (or perhaps use explicit paths to each instance).
I note that we have similar problems with "ij.jar". Our development environment is 'ant' (and I am loathe to change this). All plugins are in a "project" folder which includes ij.jar at the top level. Each plugin has a src directory (and some have a "helpers" directory under that; I have recently eliminated the "helpers" sub-directory - might that have caused my problems?)
So...going down the path of "separate .jar files for shared utilities". Assume that I separately build the shared classes and create .jar files for each one. WHERE do they go, and how do I "install" them?
Or...are there other suggestions? Again, I'd like to stay with 'ant', mostly because I want to spend time writing plugins and not coming up to speed on yet-another-development-environment. If I had my druthers, I'd still be using 'make'.
--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html