Dependency detection does not deal well with multiple update sites

[ctrueden]

This is a symptom of a general design issue relating to the usage and structure of multiple update sites, when one depends on another.

It should never be the case that, e.g., a file on the ImageJ update site is marked as having a dependency on a file from the Fiji update site, even if the byte-code analysis makes it appear like it does.

For example, recently I noticed that the Fiji update site had an edu_mines_jtk artifact, whereas the ImageJ update site had a mines-jtk one, which contained the same classes. (Some of) the components which depend on Mines JTK were flagged as depending on both of these artifacts. Marking the edu_mines_jtk obsolete on the Fiji update site appeared to work—but in a subsequent update to a file on the ImageJ update site, the updater complained that some files on the ImageJ update site had a dependency on the edu_mines_jtk component which was "about to be removed."

To fully solve this, we could make the Updater aware of the situation where one update site depends on others in the DAG. Only allow/infer dependencies up the DAG rather than from anywhere. (This structure would have many advantages beyond just fixing this issue: e.g., users could also be told that to use update site X, sites Y and Z must also be enabled.)

Another possible change would be for the Updater to defer to the metadata in a JAR file's POM regarding its dependencies, and skip the byte-code analysis completely when such metadata is present. Especially when the JAR is part of a "trusted" update site such as ImageJ and Fiji, this would make sense and avoid many of the detected circular dependencies currently plaguing the system.