NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #1208 (closed enhancement: moved)

Opened 2012-06-05T15:29:30-05:00

Last modified 2013-04-15T09:58:57-05:00

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 2012-08-07T18:36:16-05:00 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 2012-08-08T11:38:44-05:00 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 2012-08-08T17:18:03-05:00 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 2012-08-14T11:02:17-05:00 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 have a monster classpath, and not want code writing to its $HOME/.imagej folder, but rather somewhere else in a directory structure it controls.

Last edited 2012-08-14T11:02:44-05:00 by curtis

comment:5 Changed 2012-09-10T15:48:12-05:00 by curtis

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

comment:6 Changed 2013-01-22T15:14:59-06:00 by bdezonia

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

comment:7 Changed 2013-04-15T09:58:57-05:00 by curtis

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

comment:8 Changed 2014-05-01T06:07:30-05:00 by curtis

  • Status changed from new to closed
  • Resolution set to moved