Let the JavaAgent report the class loader associated with the problems

Now that we make extensive use of different class loaders, that bit of
information is crucial for debugging.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyEnvironment: Allow augmenting PluginClassLoader's class path

This adds ia method to the LegacyEnvironment that lets the user add .jar
files to the class path of the plugin class loader. That allows ImageJ
1.x environments to have their own encapsulated sets of plugins.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Heed Postel's law when the user adds the same class path entry twice

It is actually quite easy to add the same .jar file twice by mistake; we
should be gentle and manage even so to avoid the dreaded 'duplicate
plugins' message.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyEnvironment#addPluginClasspath: support adding directories

The biggest shortcoming of ImageJ 1.x is a lack of support for adding
*unpacked* plugin .jar files (as you would want when running inside an
IDE, or when running unit tests as part of a Maven build).

This commit adds support for them.

Note: the common workaround was to add the plain .class files into the
plugins/ directory of ImageJ 1.x, but that work-around falls flat on a
couple of accounts: lack of support for plugins.config (and therefore
plugin classes whose names have *no* undercore), lack of support for
dependency .jar files living somewhere completely different, the problem
that using unpacked .class files in plugins/ tests a different code path
than the intended usage, etc.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Avoid parsing ij.jar for plugins

Now that we allow adding files to the class path of the plugin class
loader, we need to be careful to skip known non-plugin .jar files, to
avoid the dreaded 'duplicate plugins' warning.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Also parse unpacked plugin .jar files *without* plugins.config

Sometimes it is quite handy to be able to run unpacked plugins lacking
a proper plugins.config, e.g. when debugging. So let's support that
use case, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Support adding a plugin class path given a ClassLoader

Sometimes you already have a class loader that knows where to find your
ImageJ 1.x plugins you want to run inside the legacy environment.

This commit adds LegacyEnvironment#addPluginClasspath(ClassLoader) to
support that use case (the plugin class loader has to load the plugin
classes separately from the given class loader, of course, so they know
about *this* legacy environment's ImageJ 1.x).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Support addPluginClasspath(ClassLoader) even with Surefire

The maven-surefire-plugin has that annoying feature that it does not put
the classes into the class path directly, but into the manifest's class
path entry of an otherwise useless .jar. Let's cope with that, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make sure that LegacyEnvironment#addPluginClasspath() works

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Avoid NullPointerException in the 'duplicate plugins' error

This could only happen if pluginsPath == null, which is now quite
possible. It could not happen earlier, but only due to side effects.
Let's be safe.

This error could be triggered by

	LegacyEnvironment ij1 = new LegacyEnvironment(null, false);
	ij1.runMacro("eval('script', 'new ImageJ(null, 2);');", "");

when plugins.dir was unset and ij1.plugin.dirs pointed to a directory
containing at least one plugin.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Handle bare .class plugins in ij1.plugin.dirs

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Avoid putting plugins from ij1.plugin.dirs into submenus

ImageJ 1.x does not remember the directory hierarchy when parsing
for plugins; instead, it reconstructs it after the fact from looking
at the absolute path name and stripping off the prefix obtained from
the system property plugin.dir. This wreaks havoc with our support
for ij1.plugin.dirs because those directories most certainly do not
have the value of plugin.dir as prefix.

So let's just skip the complete submenu determination when handling
plugins from ij1.plugin.dirs.

Together with the previous commit (to support bare .class plugins in
ij1.plugins.dir), this addresses https://github.com/fiji/fiji/issues/48.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a test to ensure correct submenus with ij1.plugin.dirs

When adding plugins via ij1.plugin.dirs, we really want the plugins to be
in Plugins, not Plugins>DIRNAME where DIRNAME happens to be the name of
the directory in which the plugin .class or .jar was found.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>