Ticket #1121 (closed enhancement: fixed)

Opened 7 years ago

Last modified 7 years ago

Teach the Updater about version numbers

Reported by: dscho Owned by: dscho
Priority: major Milestone: imagej2-b3-headless
Component: Core Version:
Severity: serious Keywords:
Cc: Blocked By:
Blocking:

Description

At the moment, the Updater is a real stickler with filenames. For example, when, say, jfreechart-1.0.13.jar is updated to jfreechart-1.0.14.jar, it complains loudly.

These problems need to be addressed:

  • when uploading a new version of a .jar, the dependencies should be updated automatically (without bothering the user with the question by which .jar the dependency should be replaced)
  • when merging entries from an update site into what was read from the local db.xml.gz, the dependencies should be handled gracefully (if local db says jfreechart-1.0.13.jar and update site says jfreechart-1.0.14.jar, the dependency should be automatically updated to the higher version number)

Change History

comment:1 Changed 7 years ago by dscho

After spending a lot of time thinking about this over the past week and trying all kinds of things, I settle for the following solution:

Rather than shunning all the low-level logic and rewriting it (which seemed quite attractive at times), the FileObject instances will still have information only from one update site.

The later the update site in the list of update sites (order is preserved when reading/writing db.xml.gz), the higher the priority.

In addition, a FileObject instance now tracks what update sites offer the same file but are overridden.

Still to be done:

  • update the dependencies automatically when the version number in the file changed
  • check version numbers upon download
  • warn appropriately when there are shadowed files (when adding an update site, when installing a new file whose dependency is shadowed, when starting up with conflicting file versions, when the file is served by a different update site than before)
  • when removing an update site, re-read the overridden update sites (implemented, but untested)
  • add special handling for Fiji (force rank(Fiji) < rank(ImageJ)
  • proper tests (halfway there at the moment)
  • probably a ton of issues I forgot to list

comment:2 Changed 7 years ago by dscho

It basically works, and there are even regression tests to prove it. Still to be done:

  • verify that the dependencies are available either from the same update site or in lower-ranked ones, warn if it is neither the same nor ImageJ nor Fiji,
  • special-case "Fiji" to be overridden always by ImageJ
  • warn when a dependency is overridden by a higher-ranked site
  • Allow reordering of update sites

Oh, and at the moment, I test it with uploading to the site... ;-)

comment:3 Changed 7 years ago by dscho

  • Milestone changed from imagej-2.0.0-beta2 to imagej-2.0.0-beta3

There was a PEBCAK here, my tests failed due to a missing re-compile of the GUI. But all is good now, the warnings still need to be put into place, and the Fiji special-casing needs to be done, too. But that's something for later (which is why I do not close this bug but I just push the remaining parts to beta3).

comment:4 Changed 7 years ago by dscho

  • Status changed from new to closed
  • Resolution set to fixed

The Updater now knows about version numbers and can handle them. The remaining issues mentioned in comment2 are actually covered by ticket #1147 (the Eau de Cologne ticket).

Note: See TracTickets for help on using tickets.