[ImageJ-devel] KNIP dynamic ImageJ plugin loading

[Johannes Schindelin]

Hi,

On Fri, 15 Jun 2012, Michael Doube wrote:

> > If you can help me with any of this, I will be very thankful.
> 
> I am a willing but slightly time-limited guinea-pig.

Thank you.

> What I would really like to see is:
> 
> 1. For users: easy (few, hard to break steps) installation of a plugin
> that has dependencies on other third-party plugins and optional ImageJ
> components.

I cannot stress enough that you are more likely to get what you want when
you participate in the process of developing things, even if you are
"just" testing things thoroughly.

That is why I am thankful that you volunteered.

Having said that, it seems that most other Fiji developers can cope with
the current Updater...

> We discussed this earlier with respect to JAMA - your response was that
> JAMA could be specified in an update site and ImageJ would take care of
> ensuring that JAMA would be available at runtime.  This helps code reuse
> and avoids the current bundling situation in BoneJ. However, I have to
> be sure that the other plugins don't change in the meantime in a way
> that breaks an API that I'm using, and screws things up for my users. So
> there has to be a versioning system that ensures compatibility between
> packages. Something like Debian's APT system is what I have in mind.
> Until then, I have to bundle code which I know works, and hope like hell
> that the rest of the ImageJ universe doesn't break things for users.

The biggest problem is that we must not make things so difficult that we
lose the developers who contribute their plugins to the community.

Yes, a situation can arise (such as with MassiveStitcher) where plugins
are incompatible with other plugins (and may even break them simply
because they are installed concurrently).

Such situations are annoying, but happily, they are also rare: there are
many more plugins which do _not_ interfer with each other, even if
depending on the same 3rd-party libraries.

In the particular case of Jama: we provide that from the main Fiji Update
site already. Since Jama has not been updated in ages, I believe that it
is safe to assume that everybody and her dog is stuck with version 1.0.2
(which we ship with one fix for a nasty JVM side effect).

> 2. For developers: easy (few, hard to break steps, passes the 'can my
> undergrad project student do it' test) to configure Eclipse to create
> plugins that have dependencies on plugins from other sources.

I am afraid that everybody I know who works with Eclipse regularly says
that it is not possible to configure Eclipse easily.

Having said that...

> Maven does this, right?

This is what I experienced. If you install Eclipse for Java developers
(_not_ Eclipse classic where they forgot to include the m2e Maven
connector), all of a sudden, configuration is pretty easy:
File>Import>Existing Maven Project...

My hope is that I'll manage to remote control Eclipse via Java to perform
that action automatically with a given path, but I did not have time to
research this yet.

> What would be super-neat would be for this to loop back to 1. above:
> when Eclipse builds a release version, the plugin and all the dependency
> info gets published to the update site.

I am of two minds there. While it would be super-convenient to upload (in
Maven speak: deploy) the build automatically as a part of the Eclipse
build (in fact, more like the Maven build steps because Eclipse is not
able to build .jar files except manually; Maven is, however, able to
perform this function automatically), it encourages a workflow where the
developer uploads _untested_ code. That would be rather dangerous, don't
you agree?

Ciao,
Johannes