Handling dependency trees for update sites

Tags: #<Tag:0x00007fb883d49f98>


Is there any guidance about handling dependency trees for update sites? On the FunImageJ update site I am doing this through Travis, and handling 1 layer deep of dependencies is kind of OK (although it does involve some hard coding artifact IDs; automatically discovering versions is fragile but works). However, dependencies that have dependencies that aren’t distributed through ImageJ is the issue I’m running into (e.g. fun.imagej depends on imagej-mesh which depends on mastodon-collection which has more dependencies).

My approach would be to use the Maven dependency tree and check which artifacts are already included in the freshly downloaded Fiji distribution, copy all missing artifacts into Fiji.app/jars/ and trigger an upload to the update site. That doesn’t sound fun, but seems doable.

Edit: An uberjar could be created, but then there will inevitably be version mismatches for core imagej dependencies.


If you take an up-to-date Fiji with no additional update sites enabled (other than yours for uploading), then run:

mvn -Dimagej.app.directory=/path/to/your/Fiji.app

and then start the updater, it should pick up all necessary dependencies, no?

Depending on other update sites (i.e. auto-activating another site when yours is enabled) is not currently possible, there were discussions in the past to improve this, but I think it’ll have to wait until a full refactoring of the update process is done.