Upgrader should keep retrying when trying to replace updater #536

[m133225]

Fixes #536

[m133225]

I don't think it's possible to upgrade the updater jar. 1) If updater jar is used as a run-time dependency: we cannot modify the updater jar 2) If updater jar is used as a separate application: we cannot pass it the notifier object for it to report its status

I think we require 2 components, each with its own update functionalities, in order to able to update any component as desired.

[m133225]

Will try the following:

• Updater jar contains a updater migrator resource (similar to JarUpdater).
• Upon downloading an update and exiting the app, the updater extracts the update migrator, and runs it as a separate application.
  • The update migrator will wait for the main application to close, then performs the update and deletes itself. (Can be done: File::deleteOnExit?) and closes. This file should be small and can be left around until the user deletes it.

EDIT: Wait, isn't this just the same as the old architecture :confused: EDIT2: I think the old architecture would be the correct way to deal with this. Kind of a waste of time but at least refactoring (both code and dependencies) & extraction of launcher jar have been done. Also, we might want to put the updater jar back into the main application. @damithc Require your input. Will attempt to clear/resolve all updater stuff by tomorrow, even if it requires a large revert change.

[damithc]

The rule we did not consider in the new architecture is that a jar cannot modify another jar on which it has a runtime dependency?

[m133225]

Yes, that's probably the case.

[damithc]

The solution is for the updatee to launch a separate updator app that will do the update when the updatee is no longer active?

[m133225]

Yes, and the updater will be left alone after the update.