Ticket #1021 (closed enhancement: fixed)
Opened 2012-02-27T15:35:09-06:00
Last modified 2012-08-07T18:28:39-05:00
Make Fiji's Updater use IJ2's Updater
| Reported by: | dscho | Owned by: | dscho |
|---|---|---|---|
| Priority: | major | Milestone: |
|
| Component: | Other | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | #807, #1378 | |
| Blocking: | #1008 |
Description (last modified by dscho)
Since the Updater code is duplicated between fiji.git and IJ2's svn so far rather than moved for real, we need to find a smooth upgrade path that users do not really need to care about.
In particular:
- some components that the Fiji update site knew about (everything IJ2 & support libraries, IJ1) should now be served from IJ2's update without complaint
- the Fiji updater should call IJ2's code. This means basically that
a) the Fiji updater should detect IJ2's Updater's presence and hand off if it finds it
b) if IJ2's Updater is not found, it should be launched directly (possibly just downloading the relevant files to update/, but how to know which ones are relevant? Do we need a Bootstrap mode for the Updater? We could use a URLClassLoader to access the URL of a known-good IJ2 updater and run the Bootstrap from there...)
c) Fiji's Updater should lose most of its code
- Fiji's update site needs to mark the components which moved to IJ2's update site as obsolete
- the IJ2 updater needs to learn that files which are current in one update site and obsoleted in an update site that comes later in the list are okay. They belong to the first update site and no complaining warning message should be issued.
One thing that the IJ2 updater already does: it initialises the list of update sites with IJ2's update site and then picks up update sites that are listed in db.xml.gz. Therefore, Fiji's update site will automatically have a lower priority than IJ2's update site. But this means that the Fiji Updater still has to write out a minimal db.xml.gz if that file does not exist already, adding the Fiji update site (otherwise no Fiji files will be updated when starting from a fresh install of Fiji Madison).
A possible complication is that Bio-Formats is bundled in Fiji as plugins/loci_tools.jar but in smaller-grained parts in IJ2. We need to make sure that the IJ1 plugin part of Bio-Formats continues to work after an upgrade.
Change History
comment:3 Changed 2012-02-27T23:02:11-06:00 by dscho
- Description modified
Just realized: for this migration path to work, the Fiji Updater needs to retain the ability to write out a minimal db.xml.gz adding the Fiji update site.
comment:4 Changed 2012-07-14T05:47:54-05:00 by dscho
Progress so far:
- the Fiji Updater was taught to hand off to the ImageJ2 Updater (commits are on the ''updater'' branch of fiji.git so far)
- the plugins Bug_Submitter and Fiji_Package_Maker were adjusted (also on the updater branch)
- manual tests show that it basically works
- the ImageJ Updater was prepared to accept update sites with checksums calculated the old way (although the Fiji update site does not contain even a single version whose checksums would differ between the old and the new way). This runs under the motto: heed Postel's law.
- the ImageJ Updater was taught to handle the case gracefully where a file was moved from one site to another (i.e. it does no longer complain that the file "is shadowed" by one site).
What needs to be done still:
- I need to mull things over to make sure I did not forget a corner case
- maybe I should switch off the date-based trigger for new-style checksums
To finalize the move,
- the ImageJ Updater needs to be uploaded since beta3 does not handle things properly when there are two update sites listing the same files but one site not offering current versions
- the Fiji Updater needs to be uploaded
- the files offered by both the ImageJ and the Fiji update site need to be removed from the Fiji update site
In particular the Postel patch should help Aivar's problem. This was due to an obsolete updater being used to upload a new file. In the future, people should be able to do things like that and things should magically work nevertheless.
comment:5 Changed 2012-07-19T23:43:38-05:00 by dscho
This took much longer than I hoped for, but it revealed a rather nasty bug I did not think possible: instead of using the update site's current version, the updater in IJ2 beta3 prefers the current version stored locally, in effect never ever updating anything. This is totally my bad, and I finally added regression tests to prevent that failure in the future.
Tomorrow, I will switch Fiji over to use the ImageJ Updater.
comment:6 Changed 2012-07-20T01:30:29-05:00 by dscho
The last two things I wanted to teach the updater were:
- to teach the updater to launch an updated updater right away, without needing to restart ImageJ, and
- to remove those loud warnings about Fiji shadowing a couple of components of ImageJ (ij-launcher.jar, for example, is served by Fiji as well as ImageJ; once we switch to the ImageJ Updater, I will make those components obsolete on the Fiji side, so they are served from ImageJ again).
comment:7 Changed 2012-07-24T17:38:47-05:00 by dscho
- Status changed from accepted to closed
- Resolution set to fixed
As of 535685b8dd4e607df39450f48b6f045e9908cab3 (and in Fiji dc6ff94c8275c6a223d60d04664709bc43713fc9) the Fiji Updater remains only a mere shell, just barely enough to hand off to the ImageJ updater. This was a monster of work, especially with all the subtle breakages introduced by 1) the versioned file names and 2) the architectural differences between Fiji and ImageJ2.
The move is complete.
comment:8 Changed 2012-08-03T12:37:51-05:00 by dscho
Unfortunately, things went not half as smooth as I hoped for. There were issues with the uploading (in contrast to what I thought, developers were not following my instructions to install the ssh uploader), and one upload completely removed sezpoz from the database, leading to NullPointerExceptions in the Fiji Updater.
These issues should be pretty much resolved now, but it is still embarrassing that even two weeks of intensive work and testing on the updater prior to the switch could not prevent these problems.