Auto-update of native application bundles

[Daniel Zwolenski]

On 19/06/2012, at 8:03 AM, Igor Nekrestyanov <igor.nekrestyanov at oracle.com> wrote:

> On 6/18/12 4:37 AM, Daniel Zwolenski wrote:
>> 
>> One niggling thing for me: how will your solution update itself while it is running? In my POC the new and old versions coexist for a time to get around the file locking issue but in yours there can be only one version.
> I think to large extent it is the same approach.

I think not quite as there is a subtle difference. 

In my POC the new jars are always named differently to the old ones because version number is appended. It's the app-profile that defines the classpath and this can be overridden by the running java (since app-profile is not locked).

In your proposal the classpath is based on what is in the 'app' directory, so if v1 and v2 were there at the same time they would both get included on the classpath. 

The result is that in my POC the new jars can be copied in while the old app is running, whereas in yours it can't. So in my POC the java GUI can show progress and success/error, whereas in yours the java GUI will have to be killed before the copy starts so the progress and success/error will have to be shown in a hard coded native UI.  

It would be nicer to allow the developer to customize in Java (eg for web page upgrade the native dialog would not work). 

Your solution could be extended to work like mine with coexisting versions if we wanted - but I think there would have to be some local file defining the jre path and classpath (eg extend the .pkg file and make it more like the app-profile) so that both versions could coexist at the same time. Of course this does open up the problem I have of when to clean the old version (on next start seems the logical choice but then it will need elevated UAC). 

It's an area I think needs further exploration in both proposals.