With the current .dmg installer, the nicely-formatted window for dragging Fiji.app to Applications is not generated properly:

• Applications folder is missing
• Window is unusually large, leading to a lot of empty space.

This is on OSX 10.10.1.

Some third party dependencies have a different version uploaded to the Fiji update site than is declared in Maven POM(s). This results in a "Locally modified" discrepancy for that library. Whenever we are using release bindings (and we indeed always use release bindings for third party dependencies) we should make sure that the POMs always reflect the version uploaded to the update site.

The first step to addressing this ticket is to build Fiji from source and make an thorough list of affected JARs. I am confident there are at least a few, but of course we need to be explicit about which JARs are skewed in this way.

See: https://list.nih.gov/cgi-bin/wa.exe?A2=ind1410&L=IMAGEJ&F=&S=&P=148646

Only affects the IJ1 Macro language.

Here is an example:

$ ./Build.sh jars/fiji-compat-2.0.0-SNAPSHOT.jar 
Skipping invalid dependency (version unset): org.slf4j/slf4j-api-null
Skipping invalid dependency (version unset): org.slf4j/slf4j-api-null
Skipping invalid dependency (version unset): org.slf4j/slf4j-api-null
Skipping invalid dependency (version unset): org.slf4j/slf4j-api-null

Clone fiji.git, run ./Build.sh followed by ./ImageJ, then run the Update Fiji command and click Manage update sites. The Fiji update site is shown to be unchecked, resulting in the Updater misreporting the current state of the installation.

Fiji (life-line version, 06/02/2014, linux-64) raises an exception upon exit and then needs to be ctrl-c'd.

Below is the stderr output.

log4j:WARN No appenders could be found for logger (org.bushe.swing.event.EventService).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
[ERROR] Skipping unsupported option -port7
Exception during disposal:
java.lang.reflect.InvocationTargetException
    at java.awt.EventQueue.invokeAndWait(EventQueue.java:1276)
    at java.awt.Window.doDispose(Window.java:1209)
    at java.awt.Window.dispose(Window.java:1147)
    at ij.ImageJ.run(ImageJ.java:767)
    at net.imagej.legacy.IJ1Helper.dispose(IJ1Helper.java:246)
    at net.imagej.legacy.ui.LegacyUI.dispose(LegacyUI.java:127)
    at org.scijava.ui.DefaultUIService.dispose(DefaultUIService.java:362)
    at org.scijava.Context.dispose(Context.java:376)
    at net.imagej.legacy.DefaultLegacyHooks.quit(DefaultLegacyHooks.java:100)
    at ij.ImageJ.quit(ImageJ.java)
    at ij.plugin.Commands.run(Commands.java:45)
    at ij.IJ.runPlugIn(IJ.java:172)
    at ij.Executer.runCommand(Executer.java:131)
    at ij.Executer.run(Executer.java:64)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: null source
    at java.util.EventObject.<init>(EventObject.java:56)
    at java.awt.AWTEvent.<init>(AWTEvent.java:337)
    at java.awt.event.InvocationEvent.<init>(InvocationEvent.java:285)
    at java.awt.event.InvocationEvent.<init>(InvocationEvent.java:174)
    at sun.awt.X11.XBaseMenuWindow.dispose(XBaseMenuWindow.java:907)
    at java.awt.MenuComponent.removeNotify(MenuComponent.java:310)
    at java.awt.Menu.removeNotify(Menu.java:198)
    at java.awt.Component.removeNotify(Component.java:6991)
    at java.awt.Container.removeNotify(Container.java:2800)
    at java.awt.Window.removeNotify(Window.java:782)
    at java.awt.Frame.removeNotify(Frame.java:1041)
    at java.awt.Window$1DisposeAction.run(Window.java:1190)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:302)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
    at java.awt.EventQueue.access$200(EventQueue.java:103)
    at java.awt.EventQueue$3.run(EventQueue.java:694)
    at java.awt.EventQueue$3.run(EventQueue.java:692)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
    at java.awt.EventQueue$4.run(EventQueue.java:708)
    at java.awt.EventQueue$4.run(EventQueue.java:706)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

When starting up Fiji, we could use the status bar to share a ProTip (a la GitHub ProTips!). It would have a link that people can click, and it would only appear after a couple of seconds displaying the current version.

These ProTips should be @Plugins, of course.

Hello,

After accepting an update to Fiji that was published today, I'm finding that the BioFormats import module fails in the process of loading OME-TIFF, at least. A quick google search turned up at least one other mention of this problem, in that case while importing .czi files.

An exception is thrown during the actual import process, after BioFormats scans the file and prompts you with a window of import options. After clicking OK to start the import, a NoSuchMethodError is thrown for org.joda.time.Instant.parse:

Full java/system information can be found here:
http://pastebin.com/9mFaBX6C

And here is the full trace:

There was a problem with the class org.joda.time.Instant which can be found here:
/Applications/Fiji.app/jars/jruby-1.6.7.2.jar
/Applications/Fiji.app/jars/joda-time-2.2.jar

WARNING: multiple locations found!
java.lang.NoSuchMethodError: org.joda.time.Instant.parse(Ljava/lang/String;Lorg/joda/time/format/DateTimeFormatter;)Lorg/joda/time/Instant;
at ome.xml.model.primitives.Timestamp.(Timestamp.java:82)
at loci.formats.MetadataTools.setDefaultCreationDate(MetadataTools.java:404)
at loci.formats.MetadataTools.populateMetadata(MetadataTools.java:234)
at loci.formats.MetadataTools.populatePixels(MetadataTools.java:138)
at loci.formats.MetadataTools.populatePixels(MetadataTools.java:101)
at loci.formats.in.MinimalTiffReader.initFile(MinimalTiffReader.java:587)
at loci.formats.FormatReader.setId(FormatReader.java:1319)
at loci.formats.in.OMETiffReader.initFile(OMETiffReader.java:711)
at loci.formats.FormatReader.setId(FormatReader.java:1319)
at loci.plugins.in.ImportProcess.initializeFile(ImportProcess.java:479)
at loci.plugins.in.ImportProcess.execute(ImportProcess.java:143)
at loci.plugins.in.Importer.showDialogs(Importer.java:141)
at loci.plugins.in.Importer.run(Importer.java:79)
at loci.plugins.LociImporter.run(LociImporter.java:81)
at ij.IJ.runUserPlugIn(IJ.java:199)
at ij.IJ.runPlugIn(IJ.java:163)
at ij.Executer.runCommand(Executer.java:131)
at ij.Executer.run(Executer.java:64)
at java.lang.Thread.run(Thread.java:695)

I think this would be a nice addition. Having to create an account on each site on the internet is a bit of bum, so this would be a nice addition. Specially since the wiki does not allow anonymous editing due to vandalism.

To reproduce (on OSX):

1. Switch to modern mode
2. Open a dataset
3. Switch to legacy mode
4. close the dataset
5. switch modern mode

There will be display flashes where the datasets used to be, as though the windows are opened again for a fraction of a second and then closed. This only happens once so I assume they are properly closed at that point.

This is a fairly minor display bug.

Now that we have multiple update sites working so well, and they can shadow upstream sites' files, it makes sense to provide two versions of Fiji:

1. A "stable Fiji" that comes with only the really well-tested stuff enabled.

2. A "kitchen sink Fiji" that comes with lots of wonderful update sites enabled, and hence has new features and bug-fixes, but potentially with new bugs and at the expense of stability.

This caters to both archetypes of users in the wild.

It would of course be possible to transform either Fiji into the other by using "Manage update sites" to add or remove update sites as desired.

We can then list both Fiji distros from http://fiji.sc/Downloads with quick blurbs explaining the difference.

Migrated-From: http://trac.imagej.net/ticket/1982

Now that we have split the Fiji repository into individual external plugin repositories, the fiji.sc/Foo.java search is much less useful. For example, http://fiji.sc/ImageJ_3D_Viewer.java does not find the 3D Viewer source code.

Specifically, Contents/MacOS/ImageJ-tiger is missing. And without ImageJ-tiger, the "Make Fiji Package" command produces an incomplete package that cannot be double-clicked (since the Info.plist references ImageJ-tiger as the starting point).

When a dependency has a classifier, MiniMaven does not always do the right thing.

The most relevant example here is miglayout with classifier swing, which is a dependency of ij-ui-swing, which is a dependency of ij-app, which is a dependency of fiji-compat. But if you run:

./fiji --mini-maven dependency-tree

And analyze the output, you'll see that the swing classifier version of miglayout is not present anywhere in the tree of dependencies. And miglayout-3.7.3.1-swing.jar is not present in the jars folder of a Fiji source tree after running ./Build.sh either.

To create an account on the FIJI wiki, one needs to answer to the question "which is the last menu on FIJI's help menu". The right answer at the moment is "Switch to Modern Mode" but the wiki still expects the old "Update FiJi"

I would suggest something very unlikely to change such as "What is the name of the figure opened when using Ctr+Shift+B ?" *although this would mean that internet access needs to be properly configured.

Freshly installed and updated Fiji, on OSX 10.10.1:

In the "Manage Update Sites" dialog, I am unable to delete any update sites.

They disappear from the list but are obviously still there. For example, if I delete the update site "SCIFIO" and then try to rename a different update site to "SCIFIO", I would get the error "Update site SCIFIO already exists!"

I also tried deleting update sites, then performing some other update, applying changes, and restarting Fiji. But the update sites persist.

The Jenkins job that updates TrackMate-dev has a dedicated Jenkins user called Jenkins-TrackMate (or similar). For consistency, we should do the same for the Bio-Formats-4 and Bio-Formats-5 jobs: rather than connecting as user "Bio-Formats" or user "Bio-Formats-5", let's call the user "Jenkins-Bio-Formats-4" and "Jenkins-Bio-Formats-5" respectively, to make it clear that it's a Jenkins account doing the updating.

Hi!
Sholl Analysis v3.4.3 (tferr/ASA@04c8655) has just been released. Could it be uploaded?
This release actually marks the publication of the plugin in Nature Methods, so let me reiterate once more that such feat would not have been possible without the incredible support of all the Fiji developers (@dscho in particular!). I do hope the paper brings even more visibility to Fiji.

*.ijm files placed in Fiji/plugins without an underscore (space) in their filenames are not appearing in their respective menus.

I'm not sure if this also happens with scripts from other languages or is exclusive to Image-J macro scripts.

(Fiji Is Just) ImageJ 1.48o; Java 1.6.0_24 [64-bit]; Windows 7 6.1; 31MB of 2959MB (1%)

java.lang.NoClassDefFoundError: imagej/core/commands/upload/SampleImageUploader
at fiji.util.Fiji_Uploader.run(Fiji_Uploader.java:26)
at ij.IJ.runUserPlugIn(IJ.java:196)
at ij.IJ.runPlugIn(IJ.java:160)
at ij.Executer.runCommand(Executer.java:131)
at ij.Executer.run(Executer.java:64)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassNotFoundException: imagej.core.commands.upload.SampleImageUploader
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 6 more

The Time Stamper plugin does not support variable width time stamps. Many of the newer microscopy file formats can store them, though, and Bio-Formats can read them. We can create a plugin to extract them and then stamp them onto the image, just like the Time Stamper does for fixed width time stamps.

The ImageJ updater shows a list of dependencies for each file. However, the versions shown there are not updated when a new version of that file is uploaded, causing them to fall out-of-date and become inconsistent with reality.

For example, as of this writing, jars/scifio.jar lists the following dependencies:

jars/imglib2-2.0.0-beta1.jar,
jars/jai_imageio-4.4-SNAPSHOT.jar,
jars/scijava-common-1.4.0.jar,
jars/mapdb-0.9.3.jar,
jars/imglib2-meta-2.0.0-beta-15.jar 

This is not correct, since no version of SCIFIO was ever released with those dependencies at those versions.

It turns out that the updater strips version suffixes anyway, effectively ignoring them when resolving dependencies. So the easiest solution here to avoid confusion is to simply strip them in the Details window as well (and/or in the db.xml.gz itself?), to avoid confusing any developers who reference this information.

Hello,
I tried using trackMate with sucess and I can track the particles within the hyperstack files from bioformats. I can then analyse everything in the channel I tracked my particles (mean intensity for example).
I there anyway of using the same track in another color or open window to analyse the particles?
I could copy the track overlay but then I can't get any data from it. Is that a limitation or I'm not finding the feature?
thanks for trackMate and best regards!

Some JAR files are present on the Fiji update site and hence available in the Fiji user distribution, but not copied into the Fiji source build's jars folder because nothing in src-plugins actually depends on them (so MiniMaven has no way of knowing to copy them). Perhaps they were uploaded to the update site manually as libraries available for use within Fiji, or perhaps they were once dependencies of Fiji plugins but no longer. Either way, they are on the update site but not known to the Fiji build system.

The solution is to add them as dependencies with <scope>runtime</scope> to the toplevel fiji component. This clues in Maven and MiniMaven that these JARs are important to Fiji, and should be copied into the jars folder, bringing Fiji-from-source more in line with Fiji-from-updater.

We should be careful to use runtime scope. In particular, dependencies such as slf4j-log4j12 and log4j need to be declared in this fashion, and in the toplevel fiji component. Otherwise, anything depending on said library will drag in the hardcoded log4j SLF4J binding, which is undesirable (this choice should be left to downstream consumers whenever possible).

Sometimes it is convenient to place a main class for testing in src/test/java, to avoid that class being bundled with the JAR artifact, but still provide access to the entry point for developers working on the source code.

And in the case of ImageJ 1.x plugins, it is often nice to use fiji-lib's convenient fiji.Debug.run(String, String) method to easily launch ImageJ and run the given plugin from an IDE such as Eclipse, even if that plugin is not actually in ImageJ's plugins folder but rather in a target build folder.

This works great when said main class is in src/main/java but unfortunately falls down for main classes beneath src/test/java with an error dialog such as:

Unrecognized command: "Grid/Collection stitching"

There are a few places in the Fiji codebase that still reference the old ImageJ2 API (imagej.* rather than net.imagej.*):

grep -IR 'import imagej' .
./Descriptor_based_registration/src/main/java/process/Matching.java:import imagej.updater.core.Diff;
./fake/src/main/java/fiji/build/Fake.java:import imagej.build.minimaven.JarClassLoader;
./fake/src/main/java/fiji/build/Fake.java:import imagej.build.minimaven.JavaCompiler;
./fake/src/main/java/fiji/build/Fake.java:import imagej.build.minimaven.JavaCompiler.CompileError;
./fake/src/main/java/fiji/build/SubFake.java:import imagej.build.minimaven.BuildEnvironment;
./fake/src/main/java/fiji/build/SubFake.java:import imagej.build.minimaven.Coordinate;
./fake/src/main/java/fiji/build/SubFake.java:import imagej.build.minimaven.JavaCompiler.CompileError;
./fake/src/main/java/fiji/build/SubFake.java:import imagej.build.minimaven.MavenProject;
./fiji/bin/analyze-dependencies.bsh:import imagej.updater.util.DependencyAnalyzer;
./fiji/bin/calculate-checksums.bsh:import imagej.updater.core.Checksummer;
./fiji/bin/calculate-checksums.bsh:import imagej.updater.core.FilesCollection;
./fiji/bin/calculate-checksums.bsh:import imagej.updater.core.FileObject;
./fiji/bin/calculate-checksums.bsh:import imagej.updater.util.StderrProgress;
./fiji/bin/updater-jar-urls.bsh:import imagej.updater.ui.CommandLine;
./fiji/native/FFMPEG_IO/ffmpeg/src/main/java/fiji/ffmpeg/CompileFFMPEG.java:import imagej.util.FileUtils;
./fiji-compat/src/main/java/fiji/patches/OldAppConfiguration.java:import imagej.legacy.plugin.LegacyAppConfiguration;
./fiji-compat/src/main/java/fiji/patches/OldLegacyEditor.java:import imagej.legacy.plugin.LegacyEditor;
./fiji-lib/src/main/java/fiji/Debug.java:import imagej.patcher.LegacyEnvironment;
./fiji-lib/src/main/java/fiji/Debug.java:import imagej.patcher.LegacyInjector;
./Script_Editor/src/main/java/fiji/scripting/FileFunctions.java:import imagej.build.minimaven.MavenProject;

Let's update those!

Sholl Analysis v3.4.1 (tferr/ASA@b5d0d7c) has just been released. Could it be uploaded?

It would be good to basically start versioning pom-fiji, based on pom-imagej and use that as an excuse to put that file into its own source code repository.

It should be possible to aggregate Javadocs using the maven-javadoc-plugin from all dependencies. Since the project defined in Fiji's external/ directory has all of the Fiji plugins as dependencies, that would provide an aggregated, full Fiji javadoc.

When running ./Build.sh from a fully built and up-to-date Fiji source tree, the following output is seen:

Looking at children of pom-fiji
Looking at children of pom-fiji-plugins
Warning: deleting '/Users/curtis/code/imagej/fiji/jars/mpicbg-20111128.jar'
Warning: deleting '/Users/curtis/code/imagej/fiji/jars/mpicbg-0.6.1-SNAPSHOT.jar'
Warning: deleting '/Users/curtis/code/imagej/fiji/jars/mpicbg-20111128.jar'
Warning: deleting '/Users/curtis/code/imagej/fiji/jars/mpicbg-0.6.1-SNAPSHOT.jar'
Warning: deleting '/Users/curtis/code/imagej/fiji/jars/mpicbg-20111128.jar'
Warning: deleting '/Users/curtis/code/imagej/fiji/jars/mpicbg-0.6.1-SNAPSHOT.jar'
Warning: deleting '/Users/curtis/code/imagej/fiji/jars/mpicbg-20111128.jar'
Warning: deleting '/Users/curtis/code/imagej/fiji/jars/mpicbg-0.6.1-SNAPSHOT.jar'
Warning: deleting '/Users/curtis/code/imagej/fiji/jars/mpicbg-20111128.jar'
Warning: deleting '/Users/curtis/code/imagej/fiji/jars/mpicbg-0.6.1-SNAPSHOT.jar'
Looking at children of pom-fiji-submodules

It would be nice to diagnose why those warnings are given, and avoid them. Obviously the Fiji project should only be depending on one version at a time of the mpicbg library (ideally a recent release version).

When following the tutorial on adding update sites, when trying to specify my Fiji wiki account, I was denied authentication but the Password field was not enabled. This resulted in me being unable to proceed.

I had already set my password for updating the Fiji main site, but had never set a personal password before.

This issue was able to be worked around by manually setting my personal update site password.

v3.4 fixes (tferr/ASA@3066bad) the known issues of previous releases. Could it be uploaded?

The documentation describing how to run scripts headless is at:
http://fiji.sc/Headless#Running_scripts_in_headless_mode

Apparently though, the -eval technique is overly complex; @dscho said in #fiji-devel that you can just pass the .jy file directly and Fiji will figure it out. Would be great to update the documentation to reflect the best, most recommended way of running scripts and macros headlessly.

Hi guys,

I am sorry, there is a problem with the build. It first worked, now it does not anymore. The descriptor-based registration that is based on the SPIM_Registration does not find the classes somehow. Jenkins builds the SPIM_Registration, but it is somehow just not there. I am really sorry, but does anyone have an idea what could be wrong?

Sorry again,
Steffi

When running ./Build.sh clean, only artifacts with current version suffixes are removed. However, it is common to occasionally see older versions of the same artifacts in the jars and plugins folders. One would expected the MiniMaven to clean those out as well when run with the clean target.

Johannes has pointed out that even though clean does not remove them, MiniMaven will remove them at build time when rebuilding those artifacts at newer versions. However, it can be argued that that behavior is less intuitive, and that furthermore, it is desirable to truly have a clean working copy without any old artifacts after clean has been run.

Recently there has been a push to make all components of Fiji build reproducibly, which will culminate in this toplevel fiji component also building reproducibly. We are getting very close, but not yet fully there. This issue is for tracking and discussion of that work.

In order for MiniMaven to use a local repository you have to add it to the <repository/> section of a pom.xml with a file:// location.

It would be great to have MiniMaven search for artifacts in a local repository when not found in the remote repositories. This would solve the problem of having to specify a reference to the local filesystem in a pom.xml that is shared in an organisation.

In an effort to "eat our own dogfood"—and also to make everything work the same way via WebDAV and not need SSH access—let's make two new Fiji wiki accounts "ImageJ" and "Fiji" and initialize update sites for them, then migrate the core ImageJ and Fiji update sites respectively into those spaces.

We will need to add redirects from the old URLs (http://update.imagej.net/ and http://fiji.sc/update) so that old versions of the ImageJ Updater continue to work.

It would be helpful if Fiji exit code was not zero when an unhandled exception (eg: java.awt.HeadlessException) is raised in headless mode... at least optionally.

Hi! Sholl Analysis v3.4.2 (tferr/ASA@0c41d41) has just been released. Could it be uploaded?

NB(and do let me know if I should ask this elsewhere):
Up to version 1.169 of pom-scijava we could use ${imagej1.version} for ij (tferr/ASA@c24ed8c). But that property no longer seems to work with 2.23. Is this intended to manually specify the required version of ij1?

It seems that the Fiji Wiki considers email addresses with a dot in the name to be invalid. At least, it reports the address [email protected] as invalid when attempting to use the email user feature. Changing the OMERO-5.0 user's email address to something without a period avoided the issue.

Further, while the address was still [email protected], attempting to send a password reset failed, while reporting success.

We really do not want to maintain two differing script editors... really...

Unfortunately, I had some trouble getting the .plugins folder and the ij1.plugins.dir system property override to work properly on my OS X system:

• When I put a plugin in $HOME/.plugins and launched Fiji, it was not discovered.
• The following command run from $HOME still did not find the plugin:

$FIJI/Contents/MacOS/ImageJ-macosx -Dij1.plugin.dirs=$HOME/.plugins

• The same command run from $HOME/.plugins did find it, but did not find the system plugins anymore.
• So then I tried the following, also from $HOME/.plugins, and it worked:

$FIJI/Contents/MacOS/ImageJ-macosx -Dij1.plugin.dirs=$FIJI/jars:$FIJI/plugins:$HOME/.plugins

But the fact that the invocation is sensitive to your CWD seems like a bug to me.

Steps to reproduce:

1. open Fiji
2. Help > Switch to modern mode
3. Run a legacy plugin (e.g. Find Jar for Class)

Now the legacy GUI pops up next to the IJ2 GUI and both are visible at the same time.

A "fat jar" is a JAR that bundles some or all of its dependencies with it. This may be fine if the dependencies are shaded (i.e., their packages are renamed). But in many cases such as the JRuby and Jython uberjars, at least some of the dependencies are not shaded. This causes problems because there are often then multiple versions of the same library available on the classpath from multiple fat jars. To avoid this problem, the Fiji update site should not include any such unshaded fat jars, but instead ship only individual JAR libraries for all its components.

This issue describes a blanket problem that we may want to file into separate issues on a per-artifact basis. There will always be some discrepancies between what is built from source (i.e., the latest master branch) and what has been uploaded to the updater (i.e., the latest tested-and-working binaries). This is a good thing.

However, at the time of this writing, there are actually many discrepancies that cannot be explained by differences in the Fiji source code itself.

1. One reason is certain dependencies present on the Fiji update site, but upon which no component of Fiji explicitly depends. See issue #37.

2. Some third party JAR versions do not match between Maven POM(s) and the Fiji update site. See issue #38.

3. Fiji has quite a few SNAPSHOT version couplings, which we likely want to phase out over time. But within fiji.git itself those couplings are very convenient, so we should carefully consider what the best approach is.

4. There are potentially other reasons for these discrepancies, which would be brought to light by an thorough examination of all differing files identified by the ImageJ updater.