Build is green
See https://jenkins.softwareheritage.org/job/DGRPH/job/tox/24/ for more details.

In D1908#44068, @zack wrote:

We certainly don't want to modify all Java files at each release.
So please either fix it the right way (which would probably mean some git subst var hackery) or at least for now just get rid of the version numbers from all Java source code - it's useless information anyway, as it belongs to the underlying VCS.

The "automatic" way is javadoc macro that updates the doc version each time it is modified, but I can also remove version and since attributes.

I'm also disturbed by the version number in the README, it would be better to have an indirection there (a generated symlink?). But it's a minor point.

I can modify the pom.xml such as suggested in https://stackoverflow.com/a/2225259 to have target/swh-graph-jar-with-dependencies.jar.

In D1908#44071, @haltode wrote:

The "automatic" way is javadoc macro that updates the doc version each time it is modified, but I can also remove version and since attributes.

Please do (remove them).

I'm also disturbed by the version number in the README, it would be better to have an indirection there (a generated symlink?). But it's a minor point.

I can modify the pom.xml such as suggested in https://stackoverflow.com/a/2225259 to have target/swh-graph-jar-with-dependencies.jar.

There's value in having a versioned .jar. For instance, we certainly want to publish that on PyPI, rather than a versionless one.
It's just that user manual instructions shouldn't force users to type the version number.
I didn't read all that thread (sorry), but if we can have both, why not.

For the symlink part, the stackoverflow post I linked was only for the jar without dependencies so it could not work. I tried with exec-maven-plugin but could not get it to bind at the end of Maven lifecycle...

Build is green
See https://jenkins.softwareheritage.org/job/DGRPH/job/tox/25/ for more details.