Make sure “latest”/“release” version on Maven Central is not the jre6/jre7 version

[maffe]

I'm submitting a ...

• bug report
• feature request

Describe the issue
The “latest version” as reported by the Central Repository Search Engine (linked on the pgjdbc download page) and the Versions Maven Plugin (mvn versions:display-dependency-updates) report the jre7 version as the latest version:
[INFO] org.postgresql:postgresql ...................... 42.2.6 -> 42.2.6.jre7

Driver Version?
42.2.6

To Reproduce
Look at https://repo.maven.apache.org/maven2/org/postgresql/postgresql/maven-metadata.xml

Expected behaviour
Metadata shows

<latest>42.2.6.jre7</latest>
<release>42.2.6.jre7</release>

but should read

<latest>42.2.6</latest>
<release>42.2.6</release>

Maybe this could be solved by changing the order of deployments or via #347. I just wanted to track this specific issue (mainly wrong reports by automated tools like the Versions plugin) independent of any planned changes which may or may not resolve the display of the latest version number.

[bokken]

This has nothing to do with release order. It is caused by how maven handles semantic versions. Anything with an additional version “segment” is considered newer.

…

On Wed, Aug 28, 2019 at 11:40 AM maffe ***@***.***> wrote: *I'm submitting a ...* - bug report - feature request *Describe the issue* The “latest version” as reported by the Central Repository Search Engine <https://search.maven.org/search?q=g:org.postgresql%20AND%20a:postgresql> (linked on the pgjdbc download page <https://jdbc.postgresql.org/download.html>) and the Versions Maven Plugin <https://www.mojohaus.org/versions-maven-plugin/> (mvn versions:display-dependency-updates <https://www.mojohaus.org/versions-maven-plugin/display-dependency-updates-mojo.html>) report the jre7 version as the latest version: [INFO] org.postgresql:postgresql ...................... 42.2.6 -> 42.2.6.jre7 *Driver Version?* 42.2.6 *To Reproduce* Look at https://repo.maven.apache.org/maven2/org/postgresql/postgresql/maven-metadata.xml *Expected behaviour* Metadata shows <latest>42.2.6.jre7</latest> <release>42.2.6.jre7</release> but should read <latest>42.2.6</latest> <release>42.2.6</release> Maybe this could be solved by changing the order of deployments or via #347 <#347>. I just wanted to track this specific issue (mainly wrong reports by automated tools like the Versions plugin) independent of any planned changes which may or may not resolve the display of the latest version number. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1551?email_source=notifications&email_token=AAW3U3NXCCPBWGATKSZUOOTQG2TANA5CNFSM4IRMHVOKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HH7IKRA>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAW3U3KEVJWCREWM7XDSMSDQG2TANANCNFSM4IRMHVOA> .

[sehrope]

Why don't all the releases have suffixes? The non-suffix version currently requires JDK 8 which already is is of varying degrees of EOL. Why not explicitly suffix it with ".jre8" so that when a ".jre11" (or whatever is next) comes along there's no ambiguity. Otherwise it'd be a different min JDK version for the same Maven coordinates depending on the driver version.

I thought this topic came up once before but I can't find anything on GitHub or the mailing list referencing it so posting it here.

[davecramer]

Well hopefully once we EOL 6 and 7 we would only have 1 jar... Is that realistic ?

[vlsi]

We could use classifiers if we migrate to Gradle.

[sehrope]

@davecramer I don't think so as the JDBC spec itself could change across versions. Ditto for possibly non-backwards compatible changes in the JDK. It's not likely that anything like that would break code in the driver but it's possible so nice to have an escape hatch.

[sehrope]

@vlsi Why does that require gradle? And would that still work for someone pulling the artifacts via regular Maven?

[vlsi]

Why does that require gradle?

Currently we use maven-release-plugin to publish releases. The plugin does not recognize classifier, thus it can't publish "jre8 jre7 and jre6" as an atomic Nexus upload.

It makes no sense to patch maven-release-plugin.

Gradle provides much better developer experience.

pulling the artifacts via regular Maven?

Yes. Lots of libraries use Gradle for build and they are consumable by Maven just fine.

[maffe]

FYI, migrating to Gradle is #1440.

[davecramer]

@vlsi is the expert at migrating to gradle!

[vlsi]

You might want to try https://github.com/apache/jmeter Gradle-based build. It is something I've implemented, so pgjdbc's build would likely look and feel very close to that.

Some Gradle commands to try can be found in https://github.com/apache/jmeter/blob/master/gradle.md

Here's an asciinema of the release process: https://asciinema.org/a/259862

[maffe]

Maven Central still shows the .jre7 JAR as the latest release.

Also the .jre7 JAR shows up as an update in org.codehaus.mojo:versions-maven-plugin:2.8.1:display-dependency-updates:

The following dependencies in Dependencies have newer versions:
  org.postgresql:postgresql .................... 42.2.22 -> 42.2.22.jre7

The project now uses Gradle (#1440), does this mean it’s now possible to fix the metadata to not have the .jre7as the latest and release version?

[bokken]

IIRC, the versions maven plug-in is simply using maven’s semantic versioning rules. Additional segments on the version are judged to be “newer”.

…

On Mon, Jun 28, 2021 at 2:49 PM maffe ***@***.***> wrote: Maven Central <https://search.maven.org/search?q=g:org.postgresql%20AND%20a:postgresql> still shows the .jre7 JAR as the latest release. Also the .jre7 JAR shows up as an update in org.codehaus.mojo:versions-maven-plugin:2.8.1:display-dependency-updates: The following dependencies in Dependencies have newer versions: org.postgresql:postgresql .................... 42.2.22 -> 42.2.22.jre7 The project now uses Gradle (#1440 <#1440>), does this mean it’s now possible to fix the metadata <https://repo.maven.apache.org/maven2/org/postgresql/postgresql/maven-metadata.xml> to not have the .jre7as the latest and release version? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1551 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW3U3PJDHDSFFCSZFM4ZY3TVDG5FANCNFSM4IRMHVOA> .

[maffe]

I fixed the versions plugin by ignoring the JRE6/7 artifacts with the following ruleset:

<?xml version="1.0" encoding="UTF-8"?>
<ruleset comparisonMethod="maven"
         xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 https://www.mojohaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
    <ignoreVersions>
        <ignoreVersion type="regex">(?i).*[.-](?:Alpha|Beta|M|RC)[0-9]+</ignoreVersion>
    </ignoreVersions>
    <rules>
        <rule groupId="org.postgresql" artifactId="postgresql">
            <ignoreVersions>
                <ignoreVersion type="regex">.*\.jre[67]</ignoreVersion>
            </ignoreVersions>
        </rule>
    </rules>
</ruleset>

Unfortunately it’s not possible to put these rules directly in a POM. See this answer for how to reference the file from a dependency to benefit from Maven’s resolution mechanism.

Now only Maven Central and the metadata display the jre7 version as an update, but for me that’s a minor issue. Maybe that can be fixed by #347.

[vlsi]

I guess there are two approaches here:
a) just drop jre6/jre7 and make it the only "backward-incompatible change for 42.3.0"
b) move jre6/jre7 suffix to the classifier

[davecramer]

I'm liking option a) above, then we can move forward with some things.