Allow passing Java arguments to the flatpak build

[3paicl]

Flatpak build 19067 from flathub

On https://josm.openstreetmap.de/wiki/Help/Preferences there are instructions that may be required for optimal usage of JOSM.

The flatpak build on Flathub (which lists this project as the owners) does not allow passing java -D arguments. All arguments are passed as josm file arguments, it seems. As a result, the user cannot apply this instructions on the mentioned page:

-Djosm.dir.name=JOSM-dev

When running flatpak run org.openstreetmap.josm -Djosm.dir.name=JOSM-dev
The output is: "JOSM: unrecognised option '-Djosm.dir.name'"

That is explained by the wrapper in /app/bin/josm. This wrapper inside the flatpak container does this:

        $JAVACMD $JAVA_OPTS -jar "${JOSM_PATH}" "$@"

Proposed solution: Parse better the arguments that are given. Arguments starting with '-D' could easily be detected and added to $JAVA_OPTS with a bit of extra shell code in the wrapper. Valid arguments for josm itself could be passed to josm.

[stoecker]

Please report this to the flatpak package maintainers: ​https://github.com/flathub/org.openstreetmap.josm

We have nothing to do with this.

[taylor.smock]

As stoecker said, we have nothing to do with this.
I have contributed to the flatpak, but I do not maintain it. I do use it for editing on my home machine.

What we could do is try reading ${XDG_CONFIG_HOME}/josm/java.opts in our startup script and parse those. However, it would require someone to write and test that patch.

This would let users of any version of JOSM on linux set their own options and would not be flatpak specific.

[taylor.smock]

Also, I think you could set the JAVA_OPTS in the environment. Example: JAVA_OPTS="-Djosm.dir.name=JOSM-dev" josm.

[anonymous]

Thank you for your feedback.

To pass Java arguments to flatpak josm, this works:

flatpak run --env=JAVA_OPTS="-Djosm.dir.name=JOSM-dev" org.openstreetmap.josm

Now I can use josm as intended.

Also I suggest reaching out to flathub to change the contact information on the listing of the flatpak.

[taylor.smock]

I assume you are talking about ​https://github.com/flathub/org.openstreetmap.josm/blob/master/org.openstreetmap.josm.appdata.xml#L31 ?

  <url type="bugtracker">https://josm.openstreetmap.de/query?report=12</url>
  <url type="homepage">https://josm.openstreetmap.de</url>
  <url type="contact">https://lists.openstreetmap.org/pipermail/josm-dev/</url>
  <url type="faq">https://josm.openstreetmap.de/wiki/Help</url>
  <url type="translate">https://josm.openstreetmap.de/wiki/Translations</url>
  <url type="vcs-browser">https://josm.openstreetmap.de/browser</url>

The bugtracker link is correct. We do accept generic bugs against josm for the flatpak. We don't accept flatpak specific issues.
The homepage link is correct.
The contact link is out-of-date (stoecker just decided to shutdown the mailing list).
The faq link is correct. (Although I might want to make a PR to change it to help)
The translate link is correct.
The vcs link is correct.

For details, see

• ​https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/#url
• ​https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-url

[anonymous]

A regular user may not differentiate between Openstreetmap and the maintainer of a third-party flatpak on Flathub. The user is directed to this site when they experience issues with the software, from Flathub. Now, after filing the issue, several people state they are not responsible for the issue. So either the support information is wrong, or you could properly redirect the issue to the flatpak maintainers on Github.

[stoecker]

Replying to anonym:

Now, after filing the issue, several people state they are not responsible for the issue. So either the support information is wrong, or you could properly redirect the issue to the flatpak maintainers on Github.

It's simply that nowadays software is a little bit more complex than software in the last century. And I'm pretty sure you don't want a list of possible bug report targets with complicated rules which to use, but rather the most important one only, as it is now. And when that's the wrong one you get told so (as I did) and directed to the right one.

It's NOT our task to forward reports ourselves, even of Taylor often does this nevertheless.

[anonymous]

If you don't want to be bothered again, since you seem to be so vehemently opposed to it, I suggest contacting Flathub and changing the metadata.