http://imagej.273.s1.nabble.com/JarUpdater-An-easy-way-to-distribute-plugin-updates-tp3685495p3685497.html
mention and can run with or without Fiji. Updating plugins and their
dependencies is a pain right now. A flexible mechanism that works with
> 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#e3dd7a63c2fe8841> You might be happier with the Plugins_Updater than with your own Fiji
> Updater site, although it is less convenient for users.
>