Conflict BoneJ SCF

Dear all,
there appear to be a conflict between SCF-MPI-CBG (@Benoit) plugins and boneJ .
I get following conflict
Particle Analyser: org.bonj.plugins.ParticleCounter and SCF_ImgTool-1.3.1.jar]

1 Like

Hey @apoliti,

thanks for your headsup! I’m currently the maintainer of “SCF” and I also wrote the Particle Analyser causing the trouble here. I just fixed the bug by renaming our menu entry. It is an experimental one anyway. Could you quickly update your Fiji and let me know if it works?




Thanks for the bug report @apoliti and the fix @haesleinhuepf.

When we released Particle Analyser in BoneJ 1.1.0 (c. Dec 2009), it was named with the UK spelling of analyse-with-an-s to avoid a naming conflict with the original Particle Analyzer in core vanilla ImageJ1. (Apparently both are wrong and should properly be named Particle Analysizer)

Is there a way in the build system / updater mechanism to warn package maintainers of these collisions, prior to them getting pushed out to users, @ctrueden?

1 Like

Don’t get a conflict anymore

1 Like

If you do manual testing you should see the “Plugin configuration error” at runtime, no?

It wouldn’t be possible to catch all possible collisions e.g. across update sites at build time. But we could consider adding something to the enforcer rules… I’m not sure where though… to catch such clashes at compile time across those components present on the compile-time classpath? If someone wants to take point on it, I’m willing to offer advice and/or rubberduck.

True - that would require an installation with all the update sites active, to catch all possible collisions.

Are you suggesting we create a CI job that enables all the update sites of ImageJ’s list of update sites? I am fairly certain there would be a large number of problems, and a lot of effort to troubleshoot them one by one. Even if we overcame/fixed most of them, I expect there would also be some that are systemic—e.g. to update sites shipping different incompatible versions of dependencies. One of the design goals of update sites is to enable this sort of thing.

We could consider introducing some kind of “friendly site” stamp for sites that don’t override core dependencies and only add their own stuff. And then make a CI job that just checks all the friendly sites together. This is more work than I have time for right now, though.

Oh - I thought the design goal was the precise opposite, to prevent projects from shipping incompatible dependencies, so that users would be safe turning on and off update sites without their whole installation behaving weirdly, à la apt.

1 Like