Postgres Pro
Downloads
Home   >   mailing lists

Thread: pgjdbc: Maven -> Gradle, Java 6 => 7, JUnit 4 => 5

pgjdbc: Maven -> Gradle, Java 6 => 7, JUnit 4 => 5

From
Vladimir Sitnikov
Date:
Hi,

It looks like its time to move forward and bump the dependencies and tools:

* Maven->Gradle

As you might know, pgjdbc is built via Maven since 2015.
It made the development, test, and release steps simpler.
It made source-based builds easier, so distributions like Fedora got up-to-date source-based pgjdbc builds.

However, Maven has certain limitations which cause confusion and inconvenience.
For instance, we had to split the code between pgjdbc and pgjdbc-parent-poms repositories, which made it hard to update dependencies.

Gradle makes build scripts more powerful, and it makes it easier to maintain the build.
For instance, with Gradle we no longer need parent-poms, the test output is way easier to understand.


The intention is to merge the PR soon, so please let me know if you find issues with it.

Even though the build system switch should not be a user-visible change, it would simplify the development.
I understand it might bring disruption to the workflows, however, I hope it won't be that bad.

* Minimal Java: 6 ==> 7 or 8

So far the minimal supported Java was Java 6. That is pgjdbc was buildable with JDK 1.6 (end of free public updates in 2013).
I guess its time to drop Java 6, and bump it to 7 or 8.

Is there a real need to support Java 7? What do you think if we require Java 8 and completely drop 6&7?

* JUnit: 4 => 5

JUnit5 makes it simpler to write certain test cases, however, it requires Java 1.8 for execution.
So far I guess

* Kotlin?

* Other?

Vladimir

Re: pgjdbc: Maven -> Gradle, Java 6 => 7, JUnit 4 => 5

From
Sehrope Sarkuni
Date:
(Re-sending as I accidentally  sent to just Vladimir)

Nice.

+1 to moving to gradle though I don't really have a strong opinion on the subject.

+1 to ditching JDK 1.6 and JDK 1.7 and requiring *at least* a min version of 1.8. If anybody wants to support something older than that let them hire your or Dave to custom build it for them :).

(Would be nice to codify a driver <> JDK version support timeline as well though does not have to happen immediately.)

+1 to general clean up of the unit tests. If it's easier to do via JUnit 5 then sure. I'd have that be a separate PR.

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/

Re: pgjdbc: Maven -> Gradle, Java 6 => 7, JUnit 4 => 5

From
Vladimir Sitnikov
Date:
Sehrope>+1 to general clean up of the unit tests. If it's easier to do via JUnit 5 then sure. I'd have that be a separate PR.

I don't intend to rewrite everything to JUnit5 immediately.
PR#1621 enables writing JUnit5 tests, however, it does run all existing JUnit4 tests just fine.
Of course, we can upgrade test by test.

Vladimir

Re: pgjdbc: Maven -> Gradle, Java 6 => 7, JUnit 4 => 5

From
Jorge Solórzano
Date:
Hi Vladimir,

* +-0 for Gradle, I don't have a strong opinion against it, but if you
think it would make it easier to maintain, its ok for me.

* +1 for drop Java 6 it's long dead now.
* +-0 for dropping Java 7, some companies are slow to move to newer
jvm versions (or are stuck on 7), but is a minor fraction that could
or should paid for support.
The reality is that even commercial JDBC drivers have long ago moved to Java 8+.

* +1 for JUnit 5

* -1 Kotlin, (let's not enter in this discussion...)

* Other -> supported versions of PostgreSQL, currently they are
supported since 8.2, released on December 5, 2006, and out of support
since December 5, 2011
that's almost 9 years supporting in the driver an unsupported version
of PostgreSQL or in other words almost 14 years of total support, I
would personally follow
a policy of Server EOL + 5 years of support (more or less 10 years for
a version), so following that would mean to drop support for 8.x, and
support (until this year) the
version 9.0 that reach EOL on October 8, 2015 (+5 years on October,
2020)... the truth is that there is not a lot of code dependent on
server version, but a smaller
removal/cleanup of code could improve maintenance and allow to have a
test matrix under control.

On Tue, Mar 10, 2020 at 9:39 PM Vladimir Sitnikov
<sitnikov.vladimir@gmail.com> wrote:
>
> Hi,
>
> It looks like its time to move forward and bump the dependencies and tools:
>
> * Maven->Gradle
>
> As you might know, pgjdbc is built via Maven since 2015.
> It made the development, test, and release steps simpler.
> It made source-based builds easier, so distributions like Fedora got up-to-date source-based pgjdbc builds.
>
> However, Maven has certain limitations which cause confusion and inconvenience.
> For instance, we had to split the code between pgjdbc and pgjdbc-parent-poms repositories, which made it hard to
updatedependencies.
 
>
> Gradle makes build scripts more powerful, and it makes it easier to maintain the build.
> For instance, with Gradle we no longer need parent-poms, the test output is way easier to understand.
>
> The PR is here: https://github.com/pgjdbc/pgjdbc/pull/1627
>
> The intention is to merge the PR soon, so please let me know if you find issues with it.
>
> Even though the build system switch should not be a user-visible change, it would simplify the development.
> I understand it might bring disruption to the workflows, however, I hope it won't be that bad.
>
> * Minimal Java: 6 ==> 7 or 8
>
> So far the minimal supported Java was Java 6. That is pgjdbc was buildable with JDK 1.6 (end of free public updates
in2013).
 
> I guess its time to drop Java 6, and bump it to 7 or 8.
>
> Is there a real need to support Java 7? What do you think if we require Java 8 and completely drop 6&7?
>
> * JUnit: 4 => 5
>
> JUnit5 makes it simpler to write certain test cases, however, it requires Java 1.8 for execution.
> So far I guess
>
> * Kotlin?
>
> * Other?
>
> Vladimir

Re: pgjdbc: Maven -> Gradle, Java 6 => 7, JUnit 4 => 5

From
Steven Schlansker
Date:
Oooh, a voting thread!  I have at least one commit so I'll consider myself qualified ;)

> On Mar 10, 2020, at 3:11 PM, Jorge Solórzano <jorsol@gmail.com> wrote:
>
> Hi Vladimir,
>
> * +-0 for Gradle, I don't have a strong opinion against it, but if you
> think it would make it easier to maintain, its ok for me.

-0 from me - I personally prefer Maven, but maintainer's choice!
Most of these "Maven issues" can be fixed but of course it's not much fun to figure out magic XML incantations to do
so.

>
> * +1 for drop Java 6 it's long dead now.

++++++1

> * +-0 for dropping Java 7, some companies are slow to move to newer
> jvm versions (or are stuck on 7), but is a minor fraction that could
> or should paid for support.

+1, 7 is dead.

> The reality is that even commercial JDBC drivers have long ago moved to Java 8+.
>
> * +1 for JUnit 5

+1

>
> * -1 Kotlin, (let's not enter in this discussion...)

Agreed -1, please keep pgJDBC as vanilla Java - no Kotlin or Scala or reactive or whatever! (until Virtual Threads hit
jdk...)
Boring and simple is a virtue, especially for drivers.

>
> * Other -> supported versions of PostgreSQL, currently they are
> supported since 8.2, released on December 5, 2006, and out of support
> since December 5, 2011
> that's almost 9 years supporting in the driver an unsupported version
> of PostgreSQL or in other words almost 14 years of total support, I
> would personally follow
> a policy of Server EOL + 5 years of support (more or less 10 years for
> a version), so following that would mean to drop support for 8.x, and
> support (until this year) the
> version 9.0 that reach EOL on October 8, 2015 (+5 years on October,
> 2020)... the truth is that there is not a lot of code dependent on
> server version, but a smaller
> removal/cleanup of code could improve maintenance and allow to have a
> test matrix under control.
>
> On Tue, Mar 10, 2020 at 9:39 PM Vladimir Sitnikov
> <sitnikov.vladimir@gmail.com> wrote:
>>
>> Hi,
>>
>> It looks like its time to move forward and bump the dependencies and tools:
>>
>> * Maven->Gradle
>>
>> As you might know, pgjdbc is built via Maven since 2015.
>> It made the development, test, and release steps simpler.
>> It made source-based builds easier, so distributions like Fedora got up-to-date source-based pgjdbc builds.
>>
>> However, Maven has certain limitations which cause confusion and inconvenience.
>> For instance, we had to split the code between pgjdbc and pgjdbc-parent-poms repositories, which made it hard to
updatedependencies. 
>>
>> Gradle makes build scripts more powerful, and it makes it easier to maintain the build.
>> For instance, with Gradle we no longer need parent-poms, the test output is way easier to understand.
>>
>> The PR is here: https://github.com/pgjdbc/pgjdbc/pull/1627
>>
>> The intention is to merge the PR soon, so please let me know if you find issues with it.
>>
>> Even though the build system switch should not be a user-visible change, it would simplify the development.
>> I understand it might bring disruption to the workflows, however, I hope it won't be that bad.
>>
>> * Minimal Java: 6 ==> 7 or 8
>>
>> So far the minimal supported Java was Java 6. That is pgjdbc was buildable with JDK 1.6 (end of free public updates
in2013). 
>> I guess its time to drop Java 6, and bump it to 7 or 8.
>>
>> Is there a real need to support Java 7? What do you think if we require Java 8 and completely drop 6&7?
>>
>> * JUnit: 4 => 5
>>
>> JUnit5 makes it simpler to write certain test cases, however, it requires Java 1.8 for execution.
>> So far I guess
>>
>> * Kotlin?
>>
>> * Other?
>>
>> Vladimir
>
>

Re: pgjdbc: Maven -> Gradle, Java 6 => 7, JUnit 4 => 5

From
Vladimir Sitnikov
Date:
>Most of these "Maven issues" can be fixed but of course it's not much fun to figure out magic XML incantations to do so.

For those who vote "+-0 for Gradle", I would definitely recommend giving it a try.
Even if you think "Maven is just enough", there's a broad (!) range of cases when Gradle beats Maven.

---

Test output in Gradle is way easier to understand.

Isn't that convincing?

Ok, here's another example:

$ maven checkstyle:check

Maven:
[INFO] --- maven-checkstyle-plugin:3.1.1:check (default-cli) @ postgresql ---
[INFO] Starting audit...
[ERROR] .../pgjdbc/src/main/java/org/postgresql/PGConnection.java:9: Import statement for 'org.postgresql.copy.CopyManager' is in the wrong order. Should be in the 'SAME_PACKAGE' group, expecting not assigned imports on this line. [CustomImportOrder]
[ERROR] .../pgjdbc/src/main/java/org/postgresql/PGConnection.java:10: Import statement for 'org.postgresql.fastpath.Fastpath' is in the wrong order. Should be in the 'SAME_PACKAGE' group, expecting not assigned imports on this line. [CustomImportOrder]
[ERROR] .../pgjdbc/src/main/java/org/postgresql/PGConnection.java:11: Import statement for 'org.postgresql.jdbc.AutoSave' is in the wrong order. Should be in the 'SAME_PACKAGE' group, expecting not assigned imports on this line. [CustomImportOrder]
[ERROR] .../pgjdbc/src/main/java/org/postgresql/PGConnection.java:12: Import statement for 'org.postgresql.jdbc.PreferQueryMode' is in the wrong order. Should be in the 'SAME_PACKAGE' group, expecting not assigned imports on this line. [CustomImportOrder]
[ERROR] .../pgjdbc/src/main/java/org/postgresql/PGConnection.java:13: Import statement for 'org.postgresql.largeobject.LargeObjectManager' is in the wrong order. Should be in the 'SAME_PACKAGE' group, expecting not assigned imports on this line. [CustomImportOrder]
[ERROR] .../pgjdbc/src/main/java/org/postgresql/PGConnection.java:14: Import statement for 'org.postgresql.replication.PGReplicationConnection' is in the wrong order. Should be in the 'SAME_PACKAGE' group, expecting not assigned imports on this line. [CustomImportOrder]
[ERROR] .../pgjdbc/src/main/java/org/postgresql/PGConnection.java:15: Import statement for 'org.postgresql.util.PGobject' is in the wrong order. Should be in the 'SAME_PACKAGE' group, expecting not assigned imports on this line. [CustomImportOrder]
[ERROR] .../pgjdbc/src/main/java/org/postgresql/PGConnection.java:17: Extra separation in import group before 'java.sql.SQLException' [CustomImportOrder]
Audit done.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.263 s
[INFO] Finished at: 2020-03-11T22:00:48+03:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:3.1.1:check (default-cli) on project postgresql: Failed during checkstyle execution: There are 8 errors reported by Checkstyle 8.29 with src/main/checkstyle/checks.xml ruleset. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException


-----

$ ./gradlew check

> Task :postgresql:autostyleJavaCheck FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':postgresql:autostyleJavaCheck'.
> The following files have format violations:
    pgjdbc/src/main/java/org/postgresql/PGConnection.java
      @@ -5,7 +5,6 @@

       package org.postgresql;

      -import java.sql.Array;
       import org.postgresql.copy.CopyManager;
       import org.postgresql.fastpath.Fastpath;
       import org.postgresql.jdbc.AutoSave;
      @@ -14,6 +13,7 @@
       import org.postgresql.replication.PGReplicationConnection;
       import org.postgresql.util.PGobject;

      +import java.sql.Array;
       import java.sql.SQLException;
       import java.sql.Statement;
       import java.util.Map;
  Run './gradlew autostyleApply' to fix the violations.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.


Vladimir

Re: pgjdbc: Maven -> Gradle, Java 6 => 7, JUnit 4 => 5

From
Philippe Marschall
Date:
On 10.03.20 21:39, Vladimir Sitnikov wrote:
> Hi,
> 
> It looks like its time to move forward and bump the dependencies and tools:
> 
> * Maven->Gradle

+/- 0 I strongly prefer Maven but I barely contribute anything. I'm fine 
with whatever the maintainers chose.

I did give it a try. In all open source projects I contribute to I'm 
underwhelmed across the board by the ones who use Gradle.

I have a personal blog and the most popular pages are the ones for 
disabling the Gradle cache and daemon.

> * Minimal Java: 6 ==> 7 or 8

+1 on 7 or 8. Personally I'd prefer 8.

> * JUnit: 4 => 5

+1

> * Kotlin?

-1

> * Other?

Nothing comes to my mind.

Cheers
Philippe

Re: pgjdbc: Maven -> Gradle, Java 6 => 7, JUnit 4 => 5

From
Tom Dunstan
Date:
On Wed, 11 Mar 2020 at 07:09, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:

* Maven->Gradle

Occasional contributor and Gradle employee here. Happy to help with any Gradle issues / best practices or find an appropriate person to ask for all pgjdbc build issues.
 
* Minimal Java: 6 ==> 7 or 8

FWIW Gradle itself requires Java 8 now (though it can build stuff for older JDK versions if required), and has since version 5.0 released in November 2018. My understanding is that we had zero pushback on that, though people could be building older stuff with it. I don't think many are in practice, though our sample may be slanted towards newer / more maintained projects.

How many pgjdbc users still on Java 7 also need the very latest driver features? I bet that number is tiny.

If we do require JDK7 support, I'd strongly recommend building with 8+ so we can use a recent Gradle and then using JDK7 in the build when compiling. I'm happy to assist with that.
 
* JUnit: 4 => 5

No strong opinion but seems like a no-brainer if upgrading to Java 8.

FWIW we use Groovy and Spock heavily for our testing, which has certain nice features like very readable parameterised tests. But whether introducing a new language to a project is worth it is never just a case of how nice it is.
 
* Kotlin?

* Other?

Was this suggesting using Kotlin for tests or something else?

Tom

Re: pgjdbc: Maven -> Gradle, Java 6 => 7, JUnit 4 => 5

From
Vladimir Sitnikov
Date:
Thanks everybody for the inputs!

I appreciate it, and hopefully, the improvements would simplify development and reviews.


Tom>If we do require JDK7 support, I'd strongly recommend building with 8+ so we can use a recent Gradle and then using JDK7 in the build when compiling

Just in case you missed, there's https://github.com/pgjdbc/pgjdbc/pull/1627 which is a fully-workable PR that migrates the build to Gradle.
The resulting build script produces Java7-compatible jar file as well.
Of course, it requires Java8+ to build (because Gradle requires that), however, it preprocesses the source files and builds with source=target=1.7 to produce -jre7.jar

Tom> then using JDK7 in the build when compiling

The real showstopper for supporting Java7 for me is JUnit5.
We do want to move forward, JUnit5 would simplify certain tests (and IDE integrations), however, JUnit5 can't be executed with Java7.

That means we can use source=target=1.7 to produce the jar, however, we do not really know if the jar works at all.

So far my plan would be as follows:

* 42.3.0 (~April): migrate to Gradle, drop Java6, keep Java7 release as an untested artifact,  enable Java 1.8 syntax in tests.
* 42.4.0 (~June): drop Java7

Tom>Was this suggesting using Kotlin for tests or something else?

My secret plan was to trigger a discussion :)
Kotlin for tests would be a significant signal to noise improvement even if we compare it with Java 1.8
Kotlin for the main code is a slightly bit different discussion.

Vladimir

Re: pgjdbc: Maven -> Gradle, Java 6 => 7, JUnit 4 => 5

From
Vladimir Sitnikov
Date:
I've migrated the build system from Maven to Gradle.
Sorry for the disruption, and I hope it won't be severe.

IDE project might probably require reimport (e.g. remove all project files, and reimport by opening Gradle build.gradle.kts).

Vladimir