| [ide-dev] Check for Updates |
|
Eike and I were recently looking at how we could most easily update
an unzipped package download for Mars.1 to include the latest
milestone build of Oomph. The experience reminded me of Mickael
Istria's thread from December 3rd titled: A "releases/latest" URL in the IDE to ease upgrades? In our case, we first tried adding http://download.eclipse.org/oomph/updates/milestone/latest to the Available Software Sites and then doing Help -> Check for Updates. Apparently there were none, though obviously we do have updates at our site. We asked ourselves, what's going on with that? If you look at Help -> Installation Details, you'll notice that for a downloaded package there is a single root feature. Only if you select that root feature is the Update... button enabled. I.e., you can only update root installable units, and there is only one (until you actually install more things using Help -> Install New Software...). Of course just hitting the Update... button doesn't do an update either in this scenario. So to update, you must use Help -> Install New Software... so that it becomes a root unit. As such, it strikes me that even if we had a new "moving target" URL from which the user can update, or even if projects contributed additional URLs for their project updates, the normal p2 update mechanism will only update if there is actually an update (different version) for the root installable unit(s). I assume of course that a new release would always a new version for each of the root units. In contrast, if you invoke Help -> Perform Setup Tasks... for an unzipped package, Oomph creates a p2 task for the root installable units known for the current profile, along with all the enabled available software site repositories in the preferences, and performs a p2 update based on that. This actually does an update in this scenario. Why? The subtle difference is that Oomph models its p2 task to be based on requirements whereas p2's normal update mechanism only supports installable units in its profile change request. To work around this limitation, Oomph creates a fake artificial root unit (it's a different synthetic version each time you perform). This artificial root captures all the requirements of the p2 task; the p2 task we synthesize currently allows only micro version increments. As a result of this approach, Perform Setup Tasks... resolves the requirements of the entire graph from scratch, and therefore finds updates wherever they might occur in the graph (and are permitted by the range requirements of the graph). Plain old p2 seems to just notice that the root unit being requested is the same as the one already installed, and decides there's nothing that needs to be done. I also wanted to point out a subtlety of using the installer to create installations. The unrestricted set of choices for the product version includes choices such as "Latest (Neon)", "Latest Releases (Mars)", "Neon", and "Mars". The subtle difference is that the two "Latest * (*)" are moving targets. I.e., when Neon releases, it will become the "Latest Release (...)", and Oomph will update the installation to that release as soon as it become available. Similarly, once the Eclipse "O*" version first becomes available as a repository, "Latest (...)" will become that version and Oomph will update the installation to the latest bleeding edge. I mention all this is to point out that there are mechanisms in place for better updates. Firstly for better support to update an installation simply by making more update sites known, and secondly better support for letting the user choose if they want their IDE stay current with the latest release, as releases become available, or prefer to remain on their chosen release until they decide they really want to move to a new one. Another problem with automatic updates to new releases is the minimum Java requirements. Someone running Mars with Java 1.7 will find that the IDE won't launch when updated to to Neon unless they have 1.8 installed as the default. To make that problem even worse, Java 1.7 cannot unpack200 *.pack.gz artifacts packed with Java 1.8's pack200. P2's reaction to that is to assume the download is corrupt, and to download it again (most likely from the same mirror); it does that 200 times before giving up and trying a different artifact form. It eventually does succeed, but it takes a very very long time. |