Auto-update of native application bundles

[Daniel Zwolenski]

I've uploaded a new MSI to: http://zenjava.com/demo/update/testapp.msi

This is version 3 and it is blue. If you install and check for updates, you
will see that version 4 is available for download. If you upgrade you will
see that it's red. Note the upgrade is now quite quick as they both use the
same Java version.

This is now all in JavaFX instead of Swing. It is a nicer UI and user
experience but it is still very raw and would need a lot of work. It should
give you more of an idea though, and, of course, if anyone wants to look at
making it nicer please let me know.

*Note: If you have the older version you can auto update to this newer
version but because the whole point is to demonstrate the new auto-update
code, you would be better served by uninstalling, downloading the new one,
installing and then upgrading. *

I'm hoping (perhaps optimistically) for feedback on the two proposed
approaches from the community regarding "deltas assembled at compile time"
vs "deltas determined at runtime" (where a 'delta' is the same thing as a
'patch'). The floor is open, but if there isn't any feedback in the next
few days I will focus on just one approach - in the absence of any other
input it will likely be Igor's "deltas assembled at compile time" approach.
Speak now or forever hold your peace (or at least apologise later when you
make me change to another way).

Just to re-cap, here are the main pros/cons of each solution:

   - with *compile-time deltas* we can assemble all the changes into one,
   easy to deploy file (per delta/OS).
   - with *runtime deltas* the app has to be uploaded to the server
   unzipped (i.e. as it would appear on your local system) so the apps can
   work out diffs on the fly

   - with *compile-time deltas* you have to create and maintain all deltas
   you want to be available (e.g. v1-to-v2, v2-to-v3 and v1-to-v3). If you
   don't provide a delta, the system reverts to 'full' update (i.e. downloads
   everything). Currently this could mean a 50MB download (instead of say a
   4MB delta), but Igor has indicated this might be reduced considerably.
   Deltas also require some extra steps at compile time to define/detect what
   has changed.
   - with *runtime deltas* you only maintain/upload the latest code - the
   apps all work out the delta's on the fly and only download what they need
   (e.g. the 4MB of jars that have changed). You do not need to create or
   maintain any deltas. You do need to maintain an 'app-profile' but this
   could be mostly generated (easily from Maven, I imagine ant could automate
   it if you used versioned jars).

   - the single file of the *compile-time deltas* make life easier/quicker
   for signing.
   - with *runtime deltas* the tool has to sign every jar individually
   (although tooling would hide this - and signing requirements are not yet
   fully explored)

There are likely other smaller benefits as well (Igor, did I miss any big
ones?) but these major ones are what I would be weighing up.

There is another possible usage of *runtime deltas* that I've not brought
up before because I still can't decide if it is a positive or a negative.
With this approach the JARs don't have to come from the same URL source, so
for example you could download the third party JARs (like hibernate,
spring, etc) directly from centralised servers - and the Maven repos
provide exactly this already. This would be useful for corporate, intranet
style apps where they could maintain their own Maven repo, but for public
apps it might be a little risky? It also opens up lots of questions
regarding JAR signing, but I personally feel signing is not as necessary in
all cases as might be the current thinking (but that's probably another
debate).

Any and all feedback on all the above will be useful for determining a
solution.