Ticket #1121 (closed enhancement: fixed)
Opened 2012-04-16T11:02:30-05:00
Last modified 2012-05-08T18:17:37-05:00
Teach the Updater about version numbers
| Reported by: | dscho | Owned by: | dscho |
|---|---|---|---|
| Priority: | major | Milestone: |
|
| 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 2012-04-23T18:26:33-05:00 by dscho
comment:2 Changed 2012-04-26T16:20:38-05:00 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 2012-04-26T17:47:27-05:00 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).
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: