Switch dependencies to io.github.openfeign.querydsl:*

[vidakovic]

It seems that QueryDSL's development is again slowing down significantly. Important dependency updates are being ignored. Driver dependencies (e. g. for PostgreSQL) are quite old. The spatial support for Postgis is outdated (package name changes).

Would it be possible to switch all dependencies to https://github.com/OpenFeign/querydsl? OpenFeign seems to have taken over the development, at least they made significant releases while maintaining backwards compatibility (mostly).

[lpandzic]

Hello, thank you for reaching out and creating a PR however I share my sentiment with spring-projects/spring-data-jpa#3335 (comment).
Since this library is built on top of existing Spring Data infrastructure and Spring Data still uses original Querydsl and exposes Querydsl API to users changing to openfeign implementation here would cause a really weird situation for users of this library.

On another note, discussions like these ones worry me:
OpenFeign/querydsl#275
OpenFeign/querydsl#141
The negative tone is persistent still in open Slack Querydsl channel and I really don't see a need for that - it's only going to push people away.

From my personal perspective, the easiest way to solve all of this would be to reach an agreement with original Querydsl owners and merge the two implementations - then all downstream problems would disappear.
Second approach is to fork and to convince all 1st level dependents to switch the implementation which is going to be hard, if not harder.

[vidakovic]

I see your concern(s)... just interested to make this stuff work and being updated properly... and I'm willing to help. I read the discussions you pointed out and can follow the issues raised... from my very small experience with this library and having tried the OpenFeign fork I have to say that things worked pretty neatly (almost drop-in replacement). Having those improvements upstream in QueryDSL would be probably the best solution. My problem is that I would really like to use QueryDSL, but if the upstream project is dormant then it might be a bit risky investing in this.

Thanks for the detailed response @lpandzic ... really like your extensions to QueryDSL. Have to think about this for a bit and see what my options are. I guess we can close this issue for now.

[velo]

From my personal perspective, the easiest way to solve all of this would be to reach an agreement with original Querydsl owners and merge the two implementations - then all downstream problems would disappear.

The original team is not interested in doing so. I could drop a series of screenshots here, but see no point.

If fork gonna be adopted or not, well, it's out of my hands. I needed a few bugs fixed for work and that was my main focus.

[lpandzic]

I needed a few bugs fixed for work and that was my main focus.

I believe this is the main issue. Querydsl has been around for about 15 years and you'll need to prove you can do better than them at this point and that you'll provide support for next 15 years. Few years simply isn't going to cut it.
To prove commitment you basically need to continue supporting it and wait for the adoption to reach critical mass where either Querydsl maintainers can no longer ignore it or the wider community accepts the fork before that.

Nevertheless in this project specifically it doesn't make sense to adopt the fork before Spring Data does because that would severely negatively impact the users of this library and because no one from Infobip is yet using the fork.
If any of those circumstances change I'll either change the implementation used or create a fork of this project (most likely in a branch).

[velo]

Well, to be fair. Querydsl is around for 15 years, but active for 12 years. Dead in the past 3.

Original maintainers of querydsl left a long while ago and the people that currently hold the keys already noticed the fork. But the attitude about merging both was "I won't maintaining code I don't know", which is quite ironical since they don't maintain the code as is now 🤣

But I agree, no need to adopt the fork. Anyone that wants it can exclude original dependencies and add fork dependencies.