search

imagej / imagej-legacy

ImageJ+ImageJ2 compatibility layer
https://imagej.net/libs/imagej-legacy
BSD 2-Clause "Simplified" License
17 stars 25 forks source link

Improve ImageJ 1.x plugin discovery #228

Closed ctrueden closed 4 years ago

ctrueden commented 4 years ago

Now, when ImageJ1 plugins are present on the system classpath, they will be noticed and parsed, even when there is no local ImageJ installation, and therefore no existing plugins folder.

Among other scenarios, this improves behavior of jgo sc.fiji:fiji, and addresses issues such as imagej/pyimagej#36.

Could anyone interested please test? (? @imagejan @haesleinhuepf @frauzufall @hadim @jluethi ?)

You can checkout this PR and build it (git clone -b plugins-on-classpath git://github.com/imagej/imagej-legacy; cd imagej-legacy; mvn clean install). If you want to use pyimagej or jgo, just mix in the custom artifact to your endpoint e.g. sc.fiji:fiji+net.imagej:imagej-legacy:0.37.0-SNAPSHOT. (If you want to be 100% certain you're mixing in the right artifact, you can change the version to something known to be unique like 999-SNAPSHOT first before running mvn clean install; and then reference it as such.)

frauzufall commented 4 years ago

Cool! Does this mean for a Fiji installation all JARs from plugins could move to jars now or does it still make sense to have these two locations for JARs?

ctrueden commented 4 years ago

Does this mean for a Fiji installation all JARs from plugins could move to jars now or does it still make sense to have these two locations for JARs?

They could—although we should be very cautious any time we change behavior away from what IJ1 expects. The JARs can all live wherever, as long as the mechanism that launches Java puts them all on the classpath. This was previous a roadblock (one of several significant ones) for switching away from the native launcher to the JavaFX packager: its standalone application bundler wanted to put all the dependencies into a single folder called lib. These days, there is jpackage, and I haven't looked yet what it wants to do.

What I think we ultimately need to do in this direction, however, is to put only the core ImageJ2 libraries into the ImageJ installation, and all plugins into a user-facing plugins directory like ~/.imagej/plugins. We could then ship core updates via the OS's favored update mechanism (package manager on Linux; Homebrew and/or App Store on macOS; Chocolatey and/or ??? on Windows; Conda for any platform; and maybe ultimately Electron's update mechanism on all platforms if we can get that working well). And then the ImageJ Updater can exist only for manipulating user-facing plugins, and can become more plugin oriented, where users toggle individual plugins rather than needing to worry about update sites explicitly.

ctrueden commented 4 years ago

I tested with pyimagej locally and it's working. There may be side effects, but we'll deal with them if/when any arise.