Posted by
Kenneth Sloan-2 on
Feb 13, 2018; 4:11pm
URL: http://imagej.273.s1.nabble.com/java-plugin-administration-advice-tp5020087.html
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