Posted by
dscho on
URL: http://imagej.273.s1.nabble.com/Install-plugin-command-should-allow-zip-files-tp5007432p5007440.html
Hi Michael,
On Fri, 25 Apr 2014, Michael Schmid wrote:
> hmmm, I would not consider it a bug that ImageJ recognizes .zip files as
> .jar. For me, if's quite handy, also apart from the problem of
> distributing plugins via email:
>
> If I have a few class files that I want to bundle with a plugins.config
> (to get the 'arg' strings for calling the plugins, and to get them into
> the correct menus), I simply mark them and zip them from the context
> menu, and then move the .zip into the plugins directory of ImageJ.
>
> If ImageJ should adopt a strict interpretation of what a .jar file should look like, I would miss this!
>
> Thus, this 'bug' makes life easier for me.
I understand that your current workflow uses this workaround. A work
around it is, though.
Have you ever considered writing your plugin in the Fiji Script Editor
(soon to be switched over to the even greater ImageJ2 script editor)?
There is a quite handy File>Make .jar command. It even has the File>Make
.jar (include sources) command.
As to mailing plugins... It has been all-too-common that spammers send out
attachments as .jar or .exe. That is why you have to use the workaround to
send a .zip.
But it really is a workaround, would you not agree?
The real problem you want to solve is that of distributing your plugin.
And by sending it via email, you definitely incur another problem: which
is the current version?
I would really like to ask you to check out the personal update sites. The
idea is that you have a simple, integrated way to work with ImageJ plugins
instead of having to resort to the Windows Explorer to bundle your plugin,
to resort to email to send the plugin, the recipient to resort to saving
the attachment, to resort to using the equivalent of the Windows explorer
to copy the plugin into the correct place, possibly removing incompatible
versions.
For the record, the design of the personal update sites does not preclude
at all using it in "plain" ImageJ 1.x (*nobody* uses plain ImageJ 1.x,
everybody installs this or that, and you can install the updater just as
well: just run File>Import>URL... and then import
http://update.imagej.net/bootstrap.js; for the moment it automatically
checks the ImageJ and the Fiji update sites, but that does not need to be
the case at all).
Also for the record, I would be delighted to have this in the "official"
ImageJ packages on
http://imagej.net/, and it was my long-term plan
anyway, but we are still stuck at a very early phase in the
https://github.com/imagej/ij1-installer project, too early still to plan
anything as big as including a Javascript running the ImageJ updater.
Ciao,
Johannes
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html