Ticket #1208 (closed enhancement: moved)

Opened 8 years ago

Last modified 7 years ago

Add support for ij.plugins.path

Reported by: curtis Owned by: curtis
Priority: major Milestone: imagej2-b11-docs
Component: Other Version:
Severity: critical Keywords:
Cc: Blocked By:
Blocking: #1207


ImageJ 1.x has a plugins.dir system property that controls the directory from which plugins are discovered. In ImageJ2 we will expand this feature to support multiple directories via an ij.plugins.path property or similar.

As an added bonus, this will aid in mitigating certain Eclipse limitations with plugin discovery. We can do a brute force scan of any JAR files that are A) present in ij.plugins.path; and B) missing up-to-date SezPoz metadata. In this way, we can avoid brute force scanning the entire Java classpath, which would be prohibitively slow.

Change History

comment:1 Changed 8 years ago by dscho

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.

comment:2 Changed 8 years ago by curtis

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?

comment:3 Changed 8 years ago by dscho

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).

comment:4 Changed 8 years ago by curtis

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 want have a monster classpath, and not want code writing to its $HOME/.imagej folder, but rather somewhere else in a directory structure it controls.

Version 0, edited 8 years ago by curtis (next)

comment:5 Changed 8 years ago by curtis

  • Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta5

comment:6 Changed 7 years ago by bdezonia

  • Milestone changed from imagej2-b7-ndim-data to imagej2-unscheduled

comment:7 Changed 7 years ago by curtis

  • Milestone changed from imagej2-unscheduled to imagej2-b11-docs

comment:8 Changed 6 years ago by curtis

  • Status changed from new to closed
  • Resolution set to moved
Note: See TracTickets for help on using tickets.