Posted by
dscho on
URL: http://imagej.273.s1.nabble.com/JarUpdater-An-easy-way-to-distribute-plugin-updates-tp3685495p3685496.html
Hi,
On Sun, 27 Feb 2011, Michael Ellis wrote:
> JarUpdater is utility class for updating an ImageJ plugin Jar file from
> the web.
>
> The code is based on, and inspired by the ij.plugin.ImageJ_Updater class
> but uses versioning information stored in the jar manifest.
>
> [...]
>
> It's very easy to use; two lines in the manifest and one line of code to
> invoke JarUpdater.
For anybody interested to know why we did not do it that way in Fiji:
- we did not want to require the manifest to need a special form,
- we did not want to require a version number of a specific form,
- we did not want to hardcode the URL in the plugin's .jar file itself,
- many advanced plugins require 3rd-party libraries in addition to ImageJ.
With the JarUpdater, this need can only be addressed by packing the
3rd-party libraries' files into the plugin's .jar file which can lead to
http://en.wikipedia.org/wiki/Dependency_hell when multiple plugins
require the same 3rd-party library.
- many advanced plugins require a certain minimal version of ImageJ (and
sometimes even a certain maximal version of ImageJ; 1.44n broke the
Image Expression Parser, for example). If all plugin information is to
be stored in the manifest, the manifests can get very bloated (because
they have to store redundant information separately) and even worse: the
manifests need to be updated _even if the plugin version does not
change_! Therefore it is hard to tell which version of a .jar file is
current even if the version number is known.
- The load required to inspect whether all local .jar files are up-to-date
does not scale well, both locally and especially on the server, when for
each and every .jar file, a connection has to be established with the
server, quite possibly requiring 3 handshakes: getting the length of the
file, seeking to the TOC, then seeking to the actual bytes of the
compressed manifest.
- there are serious problems when you overwrite .jar files that are still
in use.
Two problems would be fixable in the JarUpdater:
- .jar files can be quite large, if they bundle binary data such as
installers or large image collections. Reading in the complete .jar
file's contents into memory might fail quite easily.
- when there are errors during writing the file -- e.g. when the disk is
full or the quota is reached -- the resulting .jar file is invalid.
The multi-site feature of the Fiji Updater (which is currently in beta
test phase) might be a preferable mechanism to distribute your plugins.
You just need a web server which you can access using SSH.
Hth,
Johannes
P.S.: An updater which addresses at least two previously mentioned
problems is here:
http://groups.google.com/group/fiji-devel/browse_thread/thread/422ce3a1206b6090/e3dd7a63c2fe8841#e3dd7a63c2fe8841You might be happier with the Plugins_Updater than with your own Fiji
Updater site, although it is less convenient for users.