Update if client is newer than server-version -> Exception

[boergegrunicke]

Hi, first i think this is a realy cool project because it is easy to use and seems extremly stable. Maybe this could also be a part of #16, but we found a problem, our customer wanted to have complete installation-bundles to test the application before our update-server was present, we also implemented some new features, and shipped them with the installer and not on the server, but if the new version now checks for an update and client version is newer than the version on the update server if does something wrong, throws errors and afterwards it is not possible to start the application online or offline. would be realy cool, also a possibility for downgrade and updates for the jre would be very good.

regards

børge

[edvin]

Hi!

Right now, FXLauncher can only detect that the local version is not the same as the server version. In other words, it doesn't know if it has a newer or older version, just that it is different. I suspect that your new client will then download the older version, and this is the reason for the crash.

I will add another piece of info to the manifest so that it includes a timestamp as well. I'll also add an option to not downgrade, and set this to be the new default. That should solve your problem.

I will try to get this feature complete in a couple of days and get back to you.

As for JRE updates, this is for now handled by javapackager, so you would need to distribute a new installer to update the JRE. As mentioned in #16, we will include the ability to ship/download/update the JRE in a future rewrite. We're also looking at adding some kind of store functionality to the downloader as well. So, if you have the FXLauncher runtime installed, you can automatically launch new software from an url like fxlauncher://host/app.xml etc :)

[edvin]

I committed some code that should deal with this. Do you have time to check it out and build it locally to test if this solves your problem? Basically do a git clone then mvn install and update your version dependencies to 1.0.12-SNAPSHOT. Then rebuild the app.xml manifest file and deploy, then create a new installer with a never manifest and check that it leaves you with the current version. Then you can try to deploy a never version to your repo to see that the app updates. OK?

[boergegrunicke]

that was fast :-) i tryed with the new version and now the client downgrades and starts with the old version, i thought the downgrade should be blocked by default?

[edvin]

Yes it should, but you need to have new manifests both in the "upgraded" app and on the server. It will fail until you have updated manifests in both places. Does that make sense?

[boergegrunicke]

yes, but now i have got the new one on both, server and client and it is still downgradeing

[edvin]

OK, I'll investigate ASAP and get back to you :) Can you post both manifests?

[boergegrunicke]

so while typing this i found that the "acceptDowngrade" was automaticly set to true, so i looked into the source code and saw that you automaticly set this to true while generating the manifest, but a can not give this as a parameter, could you make it possible to give this as a parameter or even automaticliy set it to false?

[edvin]

Haha, sorry about that. I committed a fix. Will make it configurable later, but can you retry in the mean time?

[boergegrunicke]

now it works, update is working and downgrade is blocked

[edvin]

Great! I'll add an option to control the property tomorrow and release 1.0.12.

[edvin]

I added the --accept-downgrade=true|false parameter to the create manifest step. Would you like to confirm that this is working as expected before I release?

[boergegrunicke]

working good! but one idea for style in the pom.xml file: i think this

<arguments>
    <argument>${app.url}</argument>
    <argument>${app.mainClass}</argument>
    <argument>${app.dir}</argument>
    <argument>--accept-downgrade=false</argument>
</arguments>

looks a bit crazy and i think to enable or disable the downgrade possibility maybe very essential for every application, so my idea wold be to set the acceptDowngrade Parameter like you do with baseURI, launchClass and appPath.

[edvin]

A much cleaner solution would probably be to add all parameters as named. That would look better and be easier to reason about both for users and while maintaining the launcher. This would be a breaking change, but it will be implemented at some point.

For Gradle however, this is hidden, since we have a Gradle plugin. I might write a Maven plugin as well, that would make it easier to configure, and this would just be an implementation detail which I could refactor without bothering users.

[edvin]

I'm closing, will release shortly :)