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

[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 :)