Auto-update of native application bundles

[Daniel Zwolenski]

Just a brief answer to this question (I know, I talk too much):


> An XML deployment descriptor, called 'app-profile.xml' is used to describe
>> the JARs, JRE versions and other launch details - it is semantically
>> comparable to a traditional JNLP file. When an update is triggered via the
>> API, the code checks the remote URL for an updated app-profile.xml. If it
>> finds one it downloads this and checks this with its local
>> app-profile.xml.
>> Any jars that have different version numbers are downloaded, and if a new
>> JRE version is defined in the app-profile then the zip for this is
>> downloaded and extracted as well.
>>
> Where these files are placed after download?


All files are downloaded to 'temp' (i.e. File.createTempFile()), this
includes the JRE zip, which is also extracted in temp.

At the end they are moved into "Program Files/my app" (using the UAC
elevated admin process).

Since all files are version tagged, no old files are lost (i.e.
myapp-1.0.jar and myapp-2.0.jar are both in the 'app' directory), it's only
when the app-profile is updated that the new jars get used. Since the
app-profile is the last thing to be updated, if anything goes wrong the old
app-profile will still be in place so the old app will still start.

Finally, if everything succeeds the new app-profile is copied in over the
old one so the next launch will use that. In a better solution, the
obsolete old files (e.g. myapp-1.0.jar) would also be deleted now that we
have managed to start successfully.

All temp files are deleted on either success or failure.