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>