[ImageJ-devel] was: KNIP dynamic ImageJ plugin loading

[Michael Doube]

Hi Johannes,

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

This section was about ImageJ users, who are a different
super-population than Fiji developers. The updater as it stands works
fine for users. Except when it downloads updates which break their setup
and then I have to go and fix the installations on all our microscopes.
The easier and less broken it can be for users, the easier our lives as
maintainers and developers gets. Does the updater do any version
checking, or does it just download the newest of everything? What does
that mean for stability?

The point is that if I can specify that I have tested BoneJ against some
particular version of e.g. ImageJ or the 3D Viewer, then my users can
safely update those components and they can continue with their science
without some code weirdness changing their results. Otherwise they are
stuck in the assumption that newer is better - which sometimes it is not
- or they have to not update and freeze the rest of their ImageJ
installation (maybe missing out on new stuff which really is better).

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

I agree, the community has to be as inclusive as possible. But mistakes
do make it into computer programs and it would be good to protect our
users against that as far as we can.

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

You're right, JAMA wasn't a great example for the point of API changes.
I made some other examples above where API changes really have broken
things occasionally.

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

That's my experience too, hence the detailed instructions I've had to
write and attempt to keep updated. It gets easier with practice ;-)

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

That would be cool. And has a high chance of passing my student test.
(Note, this is not the same as Student's t-test).

> perform this function automatically), it encourages a workflow where the
> developer uploads _untested_ code. That would be rather dangerous, don't
> you agree?

Not necessarily any worse than the current situation. I can easily
publish code and forget to test it, without the help of Maven. But
having a "Test and Deploy" button which runs unit tests and only
publishes if they pass is one way to deal with it. Or, a warning - "this
code is going to get deployed, by hitting OK you certify that it's
tested" and then a digital signature or something like that.

I hope these comments help in some way. I'm bracing myself for the
infrastructure changes I'll have to do but looking forward to a
streamlined result.

Michael