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 _______________________________________________ ImageJ-devel mailing list [email protected] http://imagej.net/mailman/listinfo/imagej-devel
