Incorrect plugins path used

[skyper]

Edit: This problem only appears with plugins under several valid paths, see comment 7.

What steps will reproduce the problem?

1. Have several plugins with older version installed
2. In Plugin Preferences click on "Update plugins"
3. Get a message about plugins' updates
4. Close message window and preferences
5. Restart JOSM
6. Look at plugin version in Plugin Preferences.

What is the expected result?

All installed plugins are up to date

What happens instead?

Plugins with still lower local version installed

Please provide any additional information below. Attach a screenshot if possible.

Plugin update policy is set to always start without asking after update. Sadly, I did not recognize the last updates with this setting but, maybe, it helps to smaller the time range the regression was introduced.
Last plugin update seems to be 35330 but "ejml" (35313) failed before.

Edit: You need to have plugins in several valid path like .josm/cache/plugins, .local/share/JOSM/plugins, .config/JOSM/cache/plugins, /usr/share/josm/plugins or /usr/local/share/josm/plugins on Linux

In my case updates are stored under .local/share/JOSM/plugins but on startup the .jar files from .config/JOSM/cache/plugins are used.
If several paths are allowed, please, use the correct order, e.g.

1. /usr/share/josm/plugins
2. /usr/local/share/josm/plugins
3. {$HOME}/.config/[<josm.name>]/cache/plugins or {$HOME}/.josm/cache/plugins
4. {$HOME}/.local/share/[<josm.name]>/plugins

and use the highest version that fits the JOSM revision.
Thanks a lot.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-03-27 15:39:19 +0100 (Fri, 27 Mar 2020)
Revision:16205
Build-Date:2020-03-28 02:30:56
URL:https://josm.openstreetmap.de/svn/trunk

Plugins:
+ ImproveWay (29)
+ OpeningHoursEditor (35250)
+ apache-commons (35092)
+ comfort0 (35314)
+ conflation (0.6.4)
+ ejml (35122)
+ geotools (35169)
+ imagery_offset_db (35248)
+ jaxb (35092)
+ jts (35122)
+ opendata (35330)
+ reverter (35313)
+ undelete (35313)
+ utilsplugin2 (35248)
+ waydownloader (35092)

[skyper]

Strange, with settings set to update every day (1) and another restart everything is updated or did someone fix it meanwhile ?

[skyper]

Forgot to mention that I am not the only one with problem see Klumbumbus' comment 5 and followups on #19000.

[skyper]

Today it happened again. I did download the plugin updates for the third time now to only have the old version loaded on startup.

[skyper]

For the record:

• manual update with r16402 did not work, yesterday.
• version based automatically update with r16403 did work, today.

[skyper]

Ok, I found the reason for my problems.

I had an additional cache folder under .config/ with old plugins. Deleting the folder does solve the problems.

Why does JOSM refer to this old folder if a folder under .local/share/ exists and is used? This way I ran the new versions only if installed on startup.

[skyper]

Oh, in fact, this is the same problem as in #7483 and #14702 which were never fixed. Is it really not possible to have a priority in search paths and to always use the same/proper order. Or simply only support one path and only use that one.

[skyper]

See #19513 for a ticket caused by this bug.

[skyper]

See #19756 for a request about a preference setting for the plugin paths.

[GerdP]

Several problems here:

1. JOSM stores possible paths for preferences in an unordered set. This looks completely wrong. See org.openstreetmap.josm.data.Preferences.getAllPossiblePreferenceDirs()
2. When looking for the version of a plugin JOSM searches in all of those directories, sometimes in a subdirectory plugins, sometimes in the directory name with plugins appended (because it doesn't always add the separator character). This is probably not intended. On my MS Windows machine this gives

   C:\Users\Gerd\AppData\Roaming\JOSM\plugins
   C:\ProgramData\Roaming\JOSMplugins
   

3. When loading the plugins JOSM only seems to search in the user data directory, in my case C:\Users\Gerd\AppData\Roaming\JOSM\plugins

To fix the problem I think I'll just change the code that looks for the version to use the same directory as the loader.
The undordered set of preferences is also used when imgages are searched. Did not yet look at that, but it seems wrong that the order is more or less random.

[GerdP]

Hmm, this is quite confusing. The problem was introduced with r3130. Don't know if it worked at that time, but nowadays JOSM only checks one directory when loading plugins, and I think that was introduced with r2817. Still, javadoc in class PluginInformation suggests a different logic:

Try to find a plugin after some criteria. Extract the plugin-information from the plugin and return it. The plugin is searched in the following way:

    first look after an MANIFEST.MF in the package org.openstreetmap.josm.plugins.<plugin name> (After removing all fancy characters from the plugin name). If found, the plugin is loaded using the bootstrap classloader.
    If not found, look for a jar file in the user specific plugin directory (~/.josm/plugins/<plugin name>.jar)
    If not found and the environment variable JOSM_RESOURCES + "/plugins/" exist, look there.
    Try for the java property josm.resources + "/plugins/" (set via java -Djosm.plugins.path=...)
    If the environment variable ALLUSERSPROFILE and APPDATA exist, look in ALLUSERSPROFILE/<the last stuff from APPDATA>/JOSM/plugins. (*sic* There is no easy way under Windows to get the All User's application directory)
    Finally, look in some typical unix paths:
        /usr/local/share/josm/plugins/
        /usr/local/lib/josm/plugins/
        /usr/share/josm/plugins/
        /usr/lib/josm/plugins/

Most of this text was introduced in r247 (!) and wasn't changed much since then. My understanding is that I should revert r3130 and update this class to remove dead code which looks for plugins in further directories.

[GerdP]

In 17404/josm:

fix #19006: Incorrect plugins path used
revert r3130, only scan directory returned by Preferences.main().getPluginsDirectory()