> If you can help me with any of this, I will be very thankful. I am a willing but slightly time-limited guinea-pig. 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. 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. 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. Maven does this, right? 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. Looking forward to the new developments, Michael _______________________________________________ ImageJ-devel mailing list [email protected] http://imagej.net/mailman/listinfo/imagej-devel
