JOSM autoupdate

[akks]

People ask me often, why JOSM does not have auto-update feature.
Of course there are JavaWebStart and custom update-and-launch python/perl/bash scripts, but they are not suitable for novices. JWS works OK, but people are not used to it and its behavior can not be controlled from JOSM itself (and no portable version updating is possible).

I propose to introduce optional "Firefox-like" auto-updating:

• When updating is on (or user press Update button or menu item), JOSM downloads replacement JAR if needed (latest->latest, tested->tested) by DownloadFileTask.
• On next start separate launcher renames files on startup (maybe, keeping old versions) and launches newly downloaded version.

[stoecker]

I don't like that, especially as for Linux it wont work anyway.

Very likely lots of support trouble resulting from that.

[skyper]

Replying to stoecker:

I don't like that, especially as for Linux it wont work anyway.

+1

I already have problems with other java programs and there update function. It is not useful on multi-user systems.

One look at the MOTD or homepage will tell you if there is a new version available and both versions are updated on regulary bases (latest - daily, tested - first WE of month)

[akks]

The "problem" is update process - you need to download files manually. Of course, if JOSM is part of rpm/deb package, no update is possible - only for standalone JAR with launcher.

Most advanced users have scripts for it, but no novices. Maybe manual "update" button can help them? (regular automatic updates can cause support problems, I agree).

Maybe separate jar (or -exe for Windows) launcher can do the work better - simple window with "update" and big "run" button, "autoupdate" checkbox and combobox allowing to extend memory.

[stoecker]

Why not make an "update" service for Windows like all the other software is doing and simply install that with the windows exe.

If windows would provide a proper update service daemon where software could register, this would be much easier.

[Don-vip]

Replying to stoecker:

Why not make an "update" service for Windows like all the other software is doing and simply install that with the windows exe.

I don't like it neither. I judge this kind of external update processes annoying as hell, and find the internal auto-update method much better on Windows, like on Firefox and Chrome.

If windows would provide a proper update service daemon where software could register, this would be much easier.

Well, Windows 8 will be the first version to provide an application store. It is not restricted to Metro-style apps and allows FOSS, so maybe we could use this Windows Store to offer a proper update experience without developing anything (but this would cost a registration fee).

[bastiK]

Replying to stoecker:

Why not make an "update" service for Windows like all the other software is doing and simply install that with the windows exe.

Currently, the windows installer puts josm-tested.jar and a josm.exe file in the program folder. Apparently, josm.exe is a wrapper that runs josm-tested.jar and gives a helpful message when Java runtime is missing. This wrapper could also check for updates and replace the jar file before it gets executed.

[bastiK]

Replying to Don-vip:

Replying to stoecker:

If windows would provide a proper update service daemon where software could register, this would be much easier.

Well, Windows 8 will be the first version to provide an application store. It is not restricted to Metro-style apps and allows FOSS, so maybe we could use this Windows Store to offer a proper update experience without developing anything (but this would cost a registration fee).

Could work in future, but I think we need an intermediate solution.

[akks]

Replying to bastiK:

Replying to stoecker:

Why not make an "update" service for Windows like all the other software is doing and simply install that with the windows exe.

Currently, the windows installer puts josm-tested.jar and a josm.exe file in the program folder. Apparently, josm.exe is a wrapper that runs josm-tested.jar and gives a helpful message when Java runtime is missing. This wrapper could also check for updates and replace the jar file before it gets executed.

Exactly. My addition to idea is to make cross-platform jar-wrapper - it can be useful for non-windows portable installations and for Linux distributions without JOSM in repository. Anyway, default 256 Mb is not enough for heavy mapping and it can not be solved withot wrapper.

[stoecker]

Replying to akks:

Exactly. My addition to idea is to make cross-platform jar-wrapper - it can be useful for non-windows portable installations and for Linux distributions without JOSM in repository. Anyway, default 256 Mb is not enough for heavy mapping and it can not be solved withot wrapper.

Why should we add such a thing for Linux? Linux and other unix systems already have proper update mechanisms. When people don't use them, this is their own problem. There is no need to support such behaviour.

[skyper]

Replying to akks:

Anyway, default 256 Mb is not enough for heavy mapping and it can not be solved without wrapper.

This should be solved in the java settings and not within josm. E.g. fiji/imagej is also not really usable with 256mb.

Does not happen on my systems if enough RAM is available as openjdk has already a solution implemented.

[akks]

Replying to skyper:

Replying to akks:

Anyway, default 256 Mb is not enough for heavy mapping and it can not be solved without wrapper.

This should be solved in the java settings and not within josm. E.g. fiji/imagej is also not really usable with 256mb.

Does not happen on my systems if enough RAM is available as openjdk has already a solution implemented.

This is good news :)

So, for linux it will be optional of course, like JWS. Most people does not need this launcher on Linux and they do not need to download it.

I see only two reasons to make this available on linux too: for distributions that does not have JOSM in repositories and for maintainig portable JOSM (laucher can be placed on USB drive togeteher with preferences, plugins, etc. and work correctly on all OSes).

Then this launcher can replace scripts that many of advanced users have. Good working example: Hind's portable JOSM for Windows: ​http://dl.dropbox.com/u/12923490/OSM/JOSM/josm-portable.zip

[bastiK]

The preferred update mechanism on linux is rpm/apt. Maybe we can also maintain an "official" bash update script.

We should concentrate on MS Windows. This will affect a large part of our user base and as a result, we may have significantly less outdated versions in use.

[akks]

Simplest way is include curl or wget to distributive and update&run by cmd script (like Hind's distribution).

But maybe it is better to have some optional GUI with ability of memory tuning, portability and update configuration? If it will be Windows-specific, we need do implement downloader, version checker etc. in C++ for Windows only - it is much harder than use Java launcher.

[akks]

Here is VERY rough launcher code for illustrating concept

Known issues: no proxy support, no version checking, no progressbar&cancel, no translation, no silent mode, no design :)

[akks]

Do you think this could work if finished? Do you have better code or idea?

[bastiK]

IMHO, it must be a native executable and not Java:

• There might not be a Java Runtime installed on the user's system
• No one knows what to do with a *.jar file

It's all about making it easy for people with very limited technical knowledge/interest.

[akks]

Replying to bastiK:

IMHO, it must be a native executable and not Java:

• There might not be a Java Runtime installed on the user's system
• No one knows what to do with a *.jar file

It's all about making it easy for people with very limited technical knowledge/interest.

I agree, there must be exe launcher if course. We have options:

• use jSmooth to convert Jar launcher to exe too old, 32bit only
• launch4j with embedded launcher.jar in distribution
• implement launcher in winapi with no dependencies like vs2008 redist etc. Http download ? I do not want to write this bicycle myself :)

I would prefer first (need testing) or second variant, as it can give us crossplatform portable Josm as side effect.

[akks]

There is a problem: in win 7 program files dir is restricted. Where should we place downloaded josm-tested jar then? AppData?

[akks]

Here is next variant of launcher: it can check the version on startup and maually, shows progress of download and allows cancel.

It can be easily converted to EXE by launch4j, I tried.

Later "check for updates update once a day/week/..." and proxy support can be easily introduced.
Problem with "where to download josm?" still persists - I need comments.
Please try it (should work in any system, use "Portable version" checkbox to keep your main prefernces untouched)!

[bastiK]

Replying to akks:

Here is next variant of launcher: it can check the version on startup and maually, shows progress of download and allows cancel.

It can be easily converted to EXE by launch4j, I tried.

Java updater + launch4j sounds good.

Later "check for updates update once a day/week/..." and proxy support can be easily introduced.
Problem with "where to download josm?" still persists - I need comments.

How does Firefox autoupdate work on Win 7, then?

Please try it (should work in any system, use "Portable version" checkbox to keep your main prefernces untouched)!

[akks]

Replying to bastiK:

How does Firefox autoupdate work on Win 7, then?

As far as I remember, it asks administrator password if installed in no-writeable dir :) We can not do it ion Java.

So if launcher directory is not writeable, I proposee to download new versions to AppData/JOSM/updates.

Can someone give me advoce about update schedule? When it is proper time to check latest or tested Josm on server?

[akks]

Please check newer version of launcher. By default it checks newer versions once in 7 days.

System proxy support was added. Downloaded files are stored in appdata/josm or ~/.josm if current directory is inaccessible for writing.
Command line keys were introduced: -c = configure, -u = update now, -r = run without checking. By default: download new version if specified time passed (or first run) and start it automatically.

Can someone check or improve it?

[skyper]

Replying to akks:

Replying to skyper:

Can someone give me advoce about update schedule? When it is proper time to check latest or tested Josm on server?

One look at the MOTD or homepage will tell you if there is a new version available and both versions are updated on regulary bases (latest - daily, tested - first WE of month)

To be more precise the cron job for latest seems to run at 3.30 am (CET/CEST) (uses local time). (source download)

Also have a look at version, tested and latest.

[stoecker]

Autoupdate defaulting to josm latest seems no a good idea to me.

[akks]

Replying to stoecker:

Autoupdate defaulting to josm latest seems no a good idea to me.

Latest-updating is for testing purposes only, not for including into distribution.

Should we place tested/latest switcher in launcher - tested default?

[akks]

Replying to skyper:

One look at the MOTD or homepage will tell you if there is a new version available and both versions are updated on regulary bases (latest - daily, tested - first WE of month)

To be more precise the cron job for latest seems to run at 3.30 am (CET/CEST) (uses local time). (source download)

Also have a look at version, tested and latest.

Thank you.
Currently it is using josm.openstreetmap.de/latest for version checking.

[skyper]

Replying to akks:

Replying to stoecker:

Autoupdate defaulting to josm latest seems no a good idea to me.

Latest-updating is for testing purposes only, not for including into distribution.

Should we place tested/latest switcher in launcher - tested default?

and a least a comment similar to the one on the main page.

[bastiK]

Replying to akks:

Downloaded files are stored in appdata/josm or ~/.josm if current directory is inaccessible for writing.

Don't really like this fallback solution. Good reason to write some native Windows code instead of Java when it doesn't work otherwise...

[akks]

Replying to bastiK:

Replying to akks:

Downloaded files are stored in appdata/josm or ~/.josm if current directory is inaccessible for writing.

Don't really like this fallback solution. Good reason to write some native Windows code instead of Java when it doesn't work otherwise...

This is logical problem, not technical - where is the right place for ini file and dowloaded jars? This directory should be writeable without annoying admin password-askng.

I doubt if native code could help. Or you mean checking abilty to write without try-catch?

[rickmastfan67]

Replying to akks:

Downloaded files are stored in appdata/josm or ~/.josm if current directory is inaccessible for writing.

To be exact, in at least Windows 7 x64, the files are saved in "..\AppData\Roaming\JOSM".

[akks]

Replying to rickmastfan67:

Replying to akks:

Downloaded files are stored in appdata/josm or ~/.josm if current directory is inaccessible for writing.

To be exact, in at least Windows 7 x64, the files are saved in "..\AppData\Roaming\JOSM".

This directory has many hardlinks:

C:\Documents and Settings\Alexei\AppData\Roaming\JOSM
C:\Documents and Settings\Alexei\Application Data\JOSM
C:\Users\Alexei\Application Data\JOSM
C:\Users\Alexei\AppData\Roaming\JOSM

System.getenv("APPDATA") (copypasted from core) seem to work fine,

[rickmastfan67]

Ok, to be more specific, Windows 7 x64 installs of JOSM use the following:

C:\Users\<user name>\AppData\Roaming\JOSM

[akks]

Replying to rickmastfan67:

Ok, to be more specific, Windows 7 x64 installs of JOSM use the following:

C:\Users\<user name>\AppData\Roaming\JOSM

It is the same directory :) System.getenv("APPDATA") used in current version works fine (I develop on win7 64). Installing launcher to Program Files causes AppData\Roaming\JOSM directory to be used.

Question is: should APPDATA be default place for updates and launcher ini?

[akks]

Next version is ready: APPDATA/JOSM/updates is the default place for downloaded jars (if no portable), tested/latest switch and warning introduced. Please have a look.

[aceman]

A permanently running update service on Windows for JOSM would not be welcome from me :)

For your info, Firefox does install an update service but it does not permanently run. It is only invoked by the main app (Firefox) when needed. The service runs with admin privileges even if the current user is not admin. The service creates a copy of the Firefox install dir (in whatever privileged place it is), applies the patch (it downloaded a binary differential patch). When Firefox is next restarted the Firefox install dir is replaced by the contents of the patched dir (which is now fast) and Firefox is transparently started with this new version.

The auto updater would also be useful on Linux (please do not ignore it). Not all distros have a JOSM package (probably only the biggest ones have. Even then, the user may not be privileged enough to install the app systemwide from the repository. Some users may prefer to put JOSM into their home dir where it can be updated easily. In that case an updater that just automatically replaces the jar installed in this way would be useful. If you provide an official script that does this automatically (and place it near the main download) then all will be fine.

Thanks

[Don-vip]

Ticket #9336 has been marked as a duplicate of this ticket.

[jphilipz]

Yes windows is where i have the issue, and for me, i downloaded the jar file rather than the installation, so it might be good to have in the messages page for portable windows users the option to download josmlaunch.jar or simply allow the download of josmlaunch.jar from homepage.

[stoecker]

JOSM update is as easy as downloading a single file. We have update warnings telling the user and under Linux many distribution based setups.

There is much work and little benefit for OS specific update mechanisms.

[Don-vip]

Replying to stoecker:

JOSM update is as easy as downloading a single file.

I fear this will soon no longer be true. By removing WebStart and JavaFX from JRE next September, the deployment and auto-update on Windows and macOS becomes an issue.

But I have no magic solution in mind, only problems:

• it seems ​very complex to bring a Java application to the Windows Store, although ​our GPL license seems OK
• we cannot publish to the mac AppStore for license reasons, see #14117
• if we bundle JOSM and the JRE we become responsible of Java vulnerabilities for our users! So the auto-update becomes crucial
• also, if we bundle JOSM and the JRE, it could have serious impacts in terms of download bandwidth/server load
• we could maintain our JNLP for Linux users and Windows users willing to install ​IcedTea-Web for Windows, but this will only concern a few...

[Don-vip]

In case we manage to publish JOSM on the Windows Store, ​a DLL must be replaced (as for JDK 9 & 10). It should be fixed ​in theory in JDK11.