@PetrBainar and I discussed this in person. But I reply here for the benefit of others reading this thread.
The BigDataViewer specifically was an issue with version skew: the version of BDV shipped with Fiji is (as of this writing) newer than the one brought in on
sc.fiji:fiji master branch. The newer version uses the SciJava plugin mechanism for its commands, whereas the older version still uses ImageJ 1.x.
On a general note: we are trying very hard to reconcile these two things, such that Fiji from the update site always matches the latest release tag of the
sc.fiji:fiji project. And the master branch has only things that are the same or newer version. To accomplish this, we’ll need to use the automated Travis builds to auto-upload to the update site, and prohibit developers from uploading manually under normal circumstances. See fiji/fiji#38 and fiji/fiji#39 for some technical details, and to follow the progress.
In the meantime, the BDV issue you noticed is an unlucky consequence of this continuing discrepancy.
For ImageJ 1.x plugins in general, as @stelfrich points out, you must set
plugins.dir if you want ImageJ 1.x to discover them and make them available. Normally, when you execute from an IDE or from Maven via the command line, this system property is not set and thus no ImageJ 1.x plugins are available. The thing is that the classpath consists of JARs scattered in all different directories (typically all over
~/.m2/repository) so there is no one correct value for
plugins.dir. (I suppose you could set it to
~/.m2/repository but I haven’t tried it and I predict it would result in IJ1 going haywire scanning your entire Maven local repository cache.) One way to set
plugins.dir is shown in the
Finally, just to clarify: SciJava plugins in JARs on the classpath are discovered and presented in the menu structure even when running in a development environment. Your observations above are limited to ImageJ 1.x plugins only. If you notice otherwise, please let us know, since it is a bug.