JMapViewer Sources zip files contain .rej files

[sebastic]

The JMapViewer sources zip files contain BingAerialTileSource.java.rej since 2.20:

$ unzip -l ../JMapViewer-2.18-Source.zip | grep rej$
$ unzip -l ../JMapViewer-2.20-Source.zip | grep rej$
      968  2024-07-16 08:55   jmapviewer-2.20/src/org/openstreetmap/gui/jmapviewer/tilesources/BingAerialTileSource.java.rej
$ unzip -l ../JMapViewer-2.21-Source.zip | grep rej$
      968  2024-07-16 08:55   jmapviewer-2.21/src/org/openstreetmap/gui/jmapviewer/tilesources/BingAerialTileSource.java.rej

The files are not present in the SVN repo which suggests a dirty working directory is used to create the zip files.

The Debian packaging tools automatically remove .rej files in the clean target which then causes it to complain about missing files from the upstream source tree.

[taylor.smock]

In 36307/osm:

Fix #23858: Remove rej files from JMapViewer sources

[taylor.smock]

svn st doesn't show .rej files. And I don't know why.

[sebastic]

Replying to taylor.smock:

svn st doesn't show .rej files. And I don't know why.

You may have ​global-ignores configured.

It doesn't seem like svn:ignore in the osm repo is responsible, but Trac might not show svn:global-ignore properties.

[taylor.smock]

It looks like svn ignores .rej by default. See ​https://subversion.apache.org/docs/api/latest/svn__config_8h_source.html line 217.

[stoecker]

Use svn status --no-ignore ;-).

[stoecker]

P.S. From a packagers view: It's very bad habit to change the past. For the future: Better is to make a correct new release and leave the past as it was.

[taylor.smock]

Fair enough. With that said, I'm more inclined to update Nexus-JMapViewer to build the nexus jar files instead of extracting them from something we put in source control.

@sebastic: This might be a stupid question, but why aren't you using the maven sources from our nexus? Right now they are going to be the same.

@stoecker: Do you know why we put the jar files in source control? Or is it just something we've always done, so we continue to do it?

[stoecker]

Replying to taylor.smock:

@stoecker: Do you know why we put the jar files in source control?

I think Vincent started to package JMapViewer to satisfy the requests from Debian. Before it was included in JOSM codebase directly.

Or is it just something we've always done

Very likely.

, so we continue to do it?

Not necessarily. Proper download documentation on the Wiki should be enough and the link can be whatever we want.

As far as I know currently download documentation of JMapViewer is rather non-existent? Probably a page wiki:JMapViewer would be a good idea linked from downloads page and probably also from start page.

[sebastic]

Replying to stoecker:

P.S. From a packagers view: It's very bad habit to change the past. For the future: Better is to make a correct new release and leave the past as it was.

I second this. Don't modify released artifacts once published.

Replying to taylor.smock:

@sebastic: This might be a stupid question, but why aren't you using the maven sources from our nexus?

Because we've used the zip files when they became available. And our packaging tools support importing zip files in addition to tarballs, jar files are not supported.

We're using the josm source jar only for the dependency sources, the josm source we get from svn export. We have a relatively elaborate procedure to create a tarball from the various sources (svn export for JOSM sources, source JAR for dependency sources, svn export for i18n, bzr export for .po files). This is unfortunately a very custom process, we can't just run gbp import-orig --uscan to download and import a published release tarballs like we do for pretty much every other package. The JMapViewer zip file is equivalent to a release tarball from a packaging POV.

Replying to stoecker:

As far as I know currently download documentation of JMapViewer is rather non-existent? Probably a page wiki:JMapViewer would be a good idea linked from downloads page and probably also from start page.

​https://wiki.openstreetmap.org/wiki/JMapViewer links to the releases.

[taylor.smock]

source JAR for dependency sources

That is exactly what I linked to in comment:7 (https://josm.openstreetmap.de/nexus/service/local/repositories/releases/content/org/openstreetmap/jmapviewer/jmapviewer/2.21/jmapviewer-2.21-sources.jar -- note the -sources suffix).
I've updated the ​osmwiki:JMapViewer page to point at the nexus maven repo as well.

[sebastic]

Replying to taylor.smock:

source JAR for dependency sources

That is exactly what I linked to in comment:7 (https://josm.openstreetmap.de/nexus/service/local/repositories/releases/content/org/openstreetmap/jmapviewer/jmapviewer/2.21/jmapviewer-2.21-sources.jar -- note the -sources suffix).

We don't use the JMapViewer source JAR, the source JAR i meant is josm-snapshot-${SVNREV}-sources.jar. We don't use the JMapViewer sources from that since we already build that and link to the binary JAR from the jmapviewer package.

The freeplane package might be ​going away as it requires a newer gradle which practically impossible to bootstrap, if that happens we can also remove the jmapviewer package and just build it as part of josm.

[taylor.smock]

I just modified the deploy job (jenkins/job/Nexus-JMapViewer) to deploy using the pom.xml file. This won't affect the source:osm/applications/viewer/jmapviewer/releases files unfortunately -- we still have to manually build those.

@stoecker: If you are getting failure emails from Jenkins, sorry about that.

[stoecker]

Replying to taylor.smock:

@stoecker: If you are getting failure emails from Jenkins, sorry about that.

I have a very good server based mail filter. One of the advantages when hosting an own mail server ;-)