Best practices for dependencies located on multiple update sites

Tags: #<Tag:0x00007fb87c1c57c8> #<Tag:0x00007fb87c1c5638> #<Tag:0x00007fb87c1c54f8>


Hi all,

What is the recommended way to distribute a 3rd party dependency for one of my personal plugins through my update site that also appears on another update site? For better context: my plugin depends on libtensorflow_jni.jar. This .jar file also appears on the TensorFlow update site:

My concern is that there is a potential for a version conflict if a user enables and downloads the jars from both my update site and the one from TensorFlow. I do not yet know enough about update sites to tell whether there is a mechanism that supports conflict resolution such as this.

Could someone also explain shadowing to me? I’ve found it mentioned several times in messages and on the ImageJ wiki. It seems related to this problem, but I haven’t yet been able to determine what exactly it means to shadow a dependency.

I think it means either:

  1. to download a .jar from a 3rd party update site and replace the one that is intended to be used by other plugins; or
  2. to specify that a plugin on my own update site depends on a 3rd party jar located on another update site.

Thanks again everyone!


Unfortunately, there is no “recommended way.” There is no formal support for dependencies across update sites. That is, there is no way to enforce an update site needing another update site to be enabled as well. (The only “solution” I know of is: code on the OpenSPIM update site has a horrible hack to force-enable the Micro-Manager update site… but this hack causes problems and I would not recommend replicating it.)

At the moment, your options are either: A) tell users they must enable the TensorFlow update site also in order to use your update site; or B) upload the common third party dependencies to your update site as well, doing your best to ensure they are of the same/compatible versions as those on the TensorFlow update site; or C) tell users they cannot have both update sites enabled at the same time, if the versions are not actually compatible.

If you choose route (B), the pom-scijava BOM is here to help you.

Whichever update site comes later on the list (from the top down) will win.