Ticket #1208 (closed enhancement: moved)

We probably do not need ij.plugins.path at all, as long as the plugins are either in the system class path or in the class path given implicitly by a URLClassLoader that is the context class loader. The former already is looked at by CheckSezpoz, and for the latter, the only thing we might need to do for things to work is to enhance the CheckSezpoz class to look at the URLClassLoader's components.

However, even this might be overkill: for Sezpoz to work, the getResource() method of the current thread's context class loader is used. For Eclipse, we actually do not need to do much of anything because it always sets the full class path. So I actually think what we have is good enough.

My vote is to close this bug. We can always re-open it, should we find out that I was wrong.

A couple of points:

• I am concerned about environments with 100s of JAR files in the classpath, such as an OMERO server. We need to make sure CheckSezpoz is not invoked on JAR files in the normal case (which I believe it isn't, currently, so that's OK). It should really be used only as a hack to fix Eclipse brokenness.
• If we do not support ij.plugins.path, then how do you propose users would add custom plugin discovery paths? I'm sorry, but I do not understand what you mean by "in the class path given implicitly by a URLClassLoader that is the context class loader." With ImageJ1, if you want to override the plugins folder, you can say -Dplugins.dir=/foo/bar but with ImageJ2 we have no such thing. The idea is that the directories on ij.plugins.path would be scanned for JAR files to be processed by a URLClassLoader. What am I missing here?

To your first concern: yes, CheckSezpoz ignores .jar files for the moment. Eclipse does not call .jar files, but .class files (since Eclipse is too dumb to produce .jar files automatically anyway).

As to the second point, I'd rather have $HOME/.imagej/ by auto-added (recursively) to the class path by the ImageJ launcher. That way, you can have personal plugins in addition to installation-wide ones (in case you have a single, global ImageJ on a multi-user machine).

I agree about auto-adding $HOME/.imagej by default, but what if someone wants to override that path with something else? I am thinking of cases other than the typically desktop user. For example, an OMERO server process might have a monster classpath, and not want code writing to its $HOME/.imagej folder, but rather somewhere else in a directory structure it controls.

Migrated to  https://github.com/imagej/imagej/issues/64