This section is out of date, potentially misleading or invalid. Be careful with any instructions here. When in doubt, ask for help from the community.
Note: Please make sure that you have a clean build of the plugin you try to upload. You can ensure a clean build by calling the Fiji Build System with the -clean suffix before building the actual target. Example:
The graphical way (recommended)
You can use the Fiji Updater to upload new plugins (or new versions thereof). First start Help › Update Fiji . It will tell you that there are locally modified files:
Please make sure that there are no updateable files, lest you overwrite new versions with old ones. If that is the case, the Updater will automatically switch to the Advanced Mode and show you the locally modified files. By clicking on the Locally modified, you can choose to upload one or more files:
Note: if you want to upload a new file, i.e. a file Fiji does not know anything about yet, you have to switch to Advanced Mode yourself and select the view option View non-Fiji plugins only.
Please make sure that the information in the Details is correct; you can edit it by clicking into the text and modifying it in-place.
Please make sure also that the files you are about to upload are clean. You should also use the Show changes button for an extra check – in the top part, you will see information about changed and local-only/remote-only contents of the .jar file.
Once everything is ready for upload, just click the button Upload to Server.
Note: you will need to have an account on fiji.sc which is in the group updaters, and you will only be offered the upload option by the Updater if you work from a working directory with source files.
Using the command line
If you have an ssh account on fiji.sc that is in the uploaders group, you can upload plugins. To do this, run
git pull origin master
If this says that a recursive merge was performed, you had local changes and should not upload anything, as you did not test that version!
If it was a fast-forward (or if Git said “Everything up-to-date”), you are good to go:
It will refuse to upload a file that has locally-modified dependencies, and list them. To upload those dependencies, too, you can use the –auto option of ./bin/update-fiji.py. Use with care!
The original Fiji Updater was very limited; it only allowed to download new versions of files, and it did not have an option to determine whether a local version was previously installed via the Updater or not.
However, it already set the scene for the current Updater, as many people happily used the old one.
These are the building blocks of the Fiji Updater:
File versions are identified by a cryptographic hash of the file contents, and possibly the file name.
Two different methods are applied: one for .jar files and one for all the other files. For regular files, the file name (without trailing NUL nor line feed character) and the exact file contents are piped into the SHA-1 algorithm. For .jar files, the file names of the entries and the exact contents of those files are pushed through the SHA-1 algorithm, one after another.
The reason why .jar files are different is that they are really nothing more than glorified .zip files, and as such contain timestamps. If those timestamps differ, the .zip files differ. So if developer Anne Berlin compiles some plugin in Chicago and developer Dario Espana compiles the same plugin on Fiji, chances are that the timestamps are different, and therefore the .jar files, even if they contain the same ‘‘.class’ files!
Originally, the database was stored in the file current.txt, which is stored in the update/ directory of fiji.sc’s web server. Its format was simply lines in the form