querydsl ownership handover approved - owner and contributors wanted

[robertandrewbain]

On the back of the various "status of querydsl" issues, such as #2456 and this SO post, I've been in contact Timo Westkämper project owner and can confirm he's approved handover of the project, so we don't have to fork.

Firstly, let's say a huge thank you to Timo for his time, effort and talent creating this wonderful project that we all want to see succeed long term.

Now comes the difficult part. Who would like to take ownership of the project and who would like to contribute? I dip in and out due to work/life commitments and can't commit to working on it regularly.

To get the project out of its "dead" status, we need open source contributors who have the time and passion to move the codebase forward. Who's in?

[NiklasMehner]

I have posted this to the google group: https://groups.google.com/forum/#!topic/querydsl/mTJK8AqR49I so more people will see it.

I'd be willing to contribute. If there is no one willing to take over ownership i'd do it, but I'm just as happy if someone else can be found.

[robertandrewbain]

I know Atlassian had an interest, I'm keen to reach out but don't have any contacts. Can anyone help?

[NiklasMehner]

Have you tried contacting Kara Hatherly? https://groups.google.com/d/msg/querydsl/B5UOzCYbNcE/_Rhk-v3rAQAJ

[robertandrewbain]

Have you tried contacting Kara Hatherly? https://groups.google.com/d/msg/querydsl/B5UOzCYbNcE/_Rhk-v3rAQAJ

Thanks @NiklasMehner, I've reached out to Kara on the Google group and via linkedin.

[idosal]

I'm in.

[cgaolei]

That is a great news to see querydsl maybe live again. I'd like to put my name in and hopefully can do something useful for this great project with my spare time. Thanks.

[lrpinto]

Hi All,

It is great to learn about these news.

I have used QueryDSL for almost one year daily to support ORM for a REST Api based on Jersey, and I really loved it.

I would be happy to contribute for this amazing project with a few hours a week.

Cheers!

[saniam]

Hi, I'm the one who asked the Stackoverflow question.I'm definitely in. Can we get further support from Spring or Pivotal Team?

[robertandrewbain]

@saniam is that something you can action?

[robertandrewbain]

Does anyone have contact details for the devs at Atlassian, I've not heard back on google groups or linkedin. If so, can you ping them and respond on here saying you've done so?

[saniam]

1. We need to have a proper Road-map and preferably a decent literature review on the current status (Bugs,Pending items and upcoming features). Do we have any Jira for QueryDSL?
2. Yes I do have a couple of contacts in few companies (NOT Atlassian). I will ping them and get back to you @robertandrewbain

[robertandrewbain]

@saniam there's not a JIRA. There is a Slack channel though which would be good to get the conversations going. It seems there's a lot of interest in just a day. Hopefully, we can bring in some talent and get things moving. Once we have a plan in place, I'll get back to Timo for the handover.

[yygnay]

I have been using querydsl, I was still researching querydsl-sql yesterday, I am very happy to see this news, I am happy to make some contributions to this great project.

[karahatherly]

Hey there, I'm not personally in a situation to take over ownership, but I'd definitely make some contributions if we can bring it back to life. I'll ask around and see if any of my colleagues have availability and interest.

[robertandrewbain]

Hey there, I'm not personally in a situation to take over ownership, but I'd definitely make some contributions if we can bring it back to life. I'll ask around and see if any of my colleagues have availability and interest.

Brilliant, thanks Kara!

[balazs-zsoldos]

Querydsl has several sub-projects with different activity. My feeling is that the project should be divided to separate projects to let separate communities work on them. E.g.: One who contributes querydsl-sql might not be interested in querydsl-jpa and vice-versa.

The separation and different versioning would help coming out with bugfix versions for the separate modules much faster.

The whole querydsl project with all of its sub-projects is just too big for one community. What do you think?

[robertandrewbain]

@balazs-zsoldos I agree. I also think the main sub-projects that people use are querydsl-sql and querydsl-jpa. What do others think, could we leave the following behind?

• querydsl-collections
• querydsl-hibernate-search
• querydsl-jdo
• querydsl-lucene*
• querydsl-mongodb
• querydsl-scala
• querydsl-spatial
• querydsl-sql-spatial
• querydsl-sql-spring

[robertandrewbain]

Let's get things moving.

@saniam you suggested creating a road-map.
@balazs-zsoldos you suggested splitting up the project.

How about this?

Day 1:

We create 3 projects:

querydsl-core
querydsl-sql
querydsl-jpa

For each repo:

• Upgrade to the latest LTS release of Java - currently Java 11, with the intention of upgrading to new LTS versions as they arrive.
• Remove support for databases that are no longer popular.
• Minimise maven dependencies.
• Streamline CI, make the build process fast and automated releases effortless.

@NiklasMehner, @IdoSalomon, @cgaolei, @lrpinto, @yygnay, @karahatherly and those mentioned above, does this seem like a good approach?

I'm unsure about having querydsl-core as a separate repo but I can't think of a better way if we want to split the projects up. If anyone can think of one, please share your ideas.

[filipenevespinto]

Hi @robertandrewbain, I'm very happy to see querydsl moving on. As such, I'd like to thank you, and all others involved, for making it happen.

In reply to your messages, there are some points that left me thinking:

1. Are there any available statistics about the querydsl subprojects usage? It could shed some light on what to focus the effort. Although I'm pretty sure you won't be far from the truth when you suggested to go on with querydsl-sql and querydsl-jpa, there could be some other contestant... I'm crossing my fingers for querydsl-sql-spring :)
2. Wouldn't it be too much to go straight away for Java 11? It would leave behind a lot of production projects still in previous versions. I tried to search a recent and trustworthy survey and found this one: https://sdtimes.com/java/report-java-8-remains-the-most-dominant-version-of-java/

[robertandrewbain]

@filipenevespinto

1. Are there any available statistics about the querydsl subprojects usage? It could shed some light on what to focus the effort. Although I'm pretty sure you won't be far from the truth when you suggested to go on with querydsl-sql and querydsl-jpa, there could be some other contestant... I'm crossing my fingers for querydsl-sql-spring :)

It's something I'd love to know too but since it's one project / maven repo, it seems impossible to tell. Maybe others have some ideas?

1. Wouldn't it be too much to go straight away for Java 11? It would leave behind a lot of production projects still in previous versions. I tried to search a recent and trustworthy survey and found this one: https://sdtimes.com/java/report-java-8-remains-the-most-dominant-version-of-java/

It's a good point and one I've thought about (querydsl is currently on Java 6). Users have managed with no releases for a year, they'll get by. While we're in there bringing the project back to life, I think we should go most recent LTS, or it's tech debt from the start. Java houses that haven't, will be upgrading and this can be part of their road-map.

[andygoossens]

1. Are there any available statistics about the querydsl subprojects usage? It could shed some light on what to focus the effort. Although I'm pretty sure you won't be far from the truth when you suggested to go on with querydsl-sql and querydsl-jpa, there could be some other contestant... I'm crossing my fingers for querydsl-sql-spring :)

Based on an old user survey (from 2013!) published on the Mysema blog, JPA and SQL modules were the most popular: http://blog.mysema.com/2013/11/querydsl-user-survey-results.html

[murainwood]

Hi @robertandrewbain, I'm very happy to see querydsl moving on. As such, I'd like to thank you, and all others involved, for making it happen.

In reply to your messages, there are some points that left me thinking:

1. Are there any available statistics about the querydsl subprojects usage? It could shed some light on what to focus the effort. Although I'm pretty sure you won't be far from the truth when you suggested to go on with querydsl-sql and querydsl-jpa, there could be some other contestant... I'm crossing my fingers for querydsl-sql-spring :)
2. Wouldn't it be too much to go straight away for Java 11? It would leave behind a lot of production projects still in previous versions. I tried to search a recent and trustworthy survey and found this one: https://sdtimes.com/java/report-java-8-remains-the-most-dominant-version-of-java/

Hi @filipenevespinto , point 1 makes sense. I think maybe we need a online survey for subprojects usage...

[idosal]

I agree with @robertandrewbain. I think we should focus on the listed issues as a first step. In any case, a survey on usage and roadmap could help guide our efforts.
I'm very interested to hear @Shredder121's opinion.

[imeszaros]

I'm new to QueryDSL, just want to introduce it to our team and use it in our projects. I was quite disappointed by the state of the project, but these are great news! I'd happy to contribute! I like the separation of code and the proposed goals.

EDIT: another goal could be the fix showstopper issues like Hibernate 5.3 support, Eclipse APT problem, etc ASAP.

[NiklasMehner]

I think dropping jdk 8 support is a bit early. Perhaps it would be a good idea to first work through all open issues/merge requests so people who do not use jdk 11 yet have a a chance to get a updated version. Lambda expressions in jdk8 might enable us to provide a better API in some cases, but does jdk 11 offer anything relevant for querydsl?

For querydsl-jpa there will probably be a breaking change when switching to the new jakarta.* packages (I have no idea whethere there is already a timeline for migrating jpa?). So perhaps this would be a could point in time to update to jdk 11 as well.

A rough indicator of usage might be the number of maven dependencies: https://mvnrepository.com/artifact/com.mysema.querydsl

A module we should probably also look at is https://github.com/querydsl/codegen since it is needed by all (?) other modules.

[robertandrewbain]

Based on comments by @filipenevespinto and @NiklasMehner jdk8 seems like the right choice for the reasons they have outlined. I think the roadmap I suggested is too aggressive, as @NiklasMehner points out, there are issues to resolve.

Second try:

• Remove submodules that are not popular (we can decide on which ones later)
• Remove support for databases that are no longer popular (we can decide on which ones later)
• Resolve outstanding issues that relate to the subset of the codebase we're taking forward
• Upgrade to Java 8
• Minimise maven dependencies
• Get CI and release process on point

This could be querydsl 5? Day 2 we can step back and re-evaluate.

[yygnay]

@balazs-zsoldos I agree. I also think the main sub-projects that people use are querydsl-sql and querydsl-jpa. What do others think, could we leave the following behind?

• querydsl-collections
• querydsl-hibernate-search
• querydsl-jdo
• querydsl-lucene*
• querydsl-mongodb
• querydsl-scala
• querydsl-spatial
• querydsl-sql-spatial
• querydsl-sql-spring

querydsl-sql-spring is a class library integrated with querydsl-sql and spring, querydsl-sql-codegen and querydsl-maven-plugin mainly generates Qmodel of querydsl-sql, querydsl-apt mainly generates Qmodel of querydsl-jpa. Should it continue to be maintained and upgraded?

[NiklasMehner]

@robertandrewbain Sounds good to me.

@yygnay I think we have to maintain everything related to the Qmodel. Without the model querydsl will not work. querydsl-sql-spring and everything that is used by the modules we choose to keep should also be maintained. At least until we decide that the features provided by the modules are not worth the effort and should be removed.

[Shredder121]

Just chiming in, I'll still be willing to contribute, but see a few issues with splitting up everything.
We already have querydsl-contrib which was forgotten during releases.
https://github.com/querydsl/querydsl/blob/2bf234caf78549813a1e0f44d9c30ecc5ef734e3/release.sh#L27
Exactly because it was sort of independently hosted in its own repo.

Now that could be fixed by CD, or more diligently bumping the versions in all the git repos, but I just wanted to bring it up.

[Shredder121]

Also how do you all see the position of the querydsl parent project (which has hopefully all the <dependencyManagement/>? Separate repo as well, or do you have another idea?

[robertandrewbain]

@Shredder121 initially I think we're saying we wouldn't split it up and that instead, we would cut it down. We can see how it looks and think about splitting it up if we think we need to it. As above, the current suggested roadmap is:

• Remove submodules that are not popular (we can decide on which ones later)
• Remove support for databases that are no longer popular (we can decide on which ones later)
• Resolve outstanding issues that relate to the subset of the codebase we're taking forward
• Upgrade to Java 8
• Minimise maven dependencies
• Get CI and release process on point

What do you think?

[Shredder121]

Ah okay, that looks good.

[saniam]

Hi All,
I have contacted some of my people regarding the sponsorship. THEY ARE EAGER BUT A project-charter has been requested. I'm trying to prepare one. @robertandrewbain _what are our expectation from a Sponsor?_ What impacts or burdens might they face?

1. Regarding Package or Sub-module deprecation , we cannot decide on our own. Voting and proper literature review is required.
2. What is our main road-map? toward a library emphasizing more on READ or we wanna include full CRUD operations ?
3. I'm personally eager to add some Big Data features to QueryDSL (e.g. Hive , Impala, AWS, Ignite) which are more modern and in use nowadays.
4. Upgrading to latest Java version is a MUST but tricky. Many of our projects are on Licensed Application Servers and from now on Java will be forked.
5. Support for new JVM dialects and Languages (e.g. Kotlin and Scala) seems to be good, specially for Android Developers or Data Scientists.
6. Our current setup is not functional. we need a JIRA to do proper profiling (for each component). We can get one from this link (https://www.atlassian.com/software/views/open-source-license-request)
7. I'm trying to setup a SonarQube (please tell me if you have already a Metrics Reports) , to do an estimation of the efforts which are required to rehabilitate the repository.
8. Few years back QueryDSL was an inseparable dependency in a Spring Data project, Before removing anything please THINK twice. We can have multiple swimlines and Build routines when we have CI/CD.
9. I'm trying to prepare a very short but comprehensive mini Project Charter. Till then, I won't commit a single line of code.
10. I always appreciate your kind, constructive and fruitful opinion and suggestions. Please write your comments here, so I can compile them in my final artifact.

Regards
Saniam

[robertandrewbain]

sponsorship

@saniam what do you mean by sponsorship and by who?

[saniam]

@robertandrewbain here: https://github.com/querydsl/querydsl/issues/2459#issuecomment-508270427 and https://github.com/querydsl/querydsl/issues/2459#issuecomment-508581638

[pslootweg]

I believe removing anything should be bottom of the list.

Top of the list is engage enough developers to make the project viable.

Then a decision is required on if/how to review/merge the many PRs already waiting - assuming they are bug fixes. I'm not sure new features should be added yet.
There is definitely strong case to move to Java 8.

But if this project doesn't come back to life soon (without becoming a free development program for any 'sponsor') then we might as well admit defeat now.

[robertandrewbain]

@robertandrewbain here: #2459 (comment) and #2459 (comment)

@saniam that doesn't answer either of my questions. I still don't know what you mean by "sponsorship" and "NOT Atlassian" isn't a helpful answer. Please elaborate.

[robertandrewbain]

@pslootweg I agree with (nearly) all of your points, particularly on merging current prs. I think we should remove things, however.

We need to address the reasons why querydsl has become in its current "dead" state and make changes that look likely to support a positive outcome. I believe that if we focus on the most popular areas of the project, we'll reduce the complexity and maintenance overhead. It will lead to a querydsl with less functionality but we'll keep the important bits and enhance from there. What do you think?

[robertandrewbain]

@NiklasMehner, @IdoSalomon, @cgaolei, @lrpinto, @saniam, @yygnay, @karahatherly, @balazs-zsoldos, @filipenevespinto, @andygoossens, @murainwood, @imeszaros, @Shredder121, @pslootweg

We all definitely agree that we want querydsl to succeed into the future. Let's find common ground and make it happen.

This github issue isn't a suitable forum for the conversations we need to have. I've created a slack workspace. I think we can discuss and vote on there: https://join.slack.com/t/querydsl-ownership/shared_invite/enQtNjk0MTI3MjI1OTc1LTM3ZjhjMzVmMzEwMDFhOGViMDBhMjJhYTkzOTU5MThjNWExMzJhZDM4YmY5NjA4NTU3ZGQ3NDRlOGNlZGQ5NTY

[vnobo]

I'm in.

[InternetPseudonym]

if you guys need hosting and/or domain transfer of querydsl.com i could chime in - i'd be willing to put it onto one of my servers or into AWS (completely free, of course)
Im currently unable to participate in development but its not completely out of question, i just need to raise my kid until preschool :-)

I think you should also initiate the transfer of the github repo ownership - someone needs to be able to manage all of this right here without restrictions

Also : i'd highly recommend against corporate ownership - that'll guarantee a downfall of querydsl since it will surely be converted into a commercial, non-free product. Please keep it entirely free and open source forever ... drop dev-support if you have to but never hand it over to a corporation.

[edobry]

I've used querydsl for years and love the project, excited to see it revitalized and pushed forward. Willing to contribute code and help with stewardship when the ball gets rolling.

[johnjaylward]

@InternetPseudonym it would probably be best to just move the website to the github.io platform so that whoever is maintaining the project can also manage the web site. I don't see a reason to incur costs that self-hosting would entail.

[InternetPseudonym]

I don't see a reason to incur costs that self-hosting would entail.

please read my comment again. There are no "costs". My servers are already paid for _(they are cheaper than quite a few types of food i buy literally every day of my life)_ and AWS can be used without generating any costs. This is the 21st century.

[johnjaylward]

@InternetPseudonym there would be costs to you, and if you didn't feel like, or couldn't pay the bill, it would leave the project in an iffy position. There isn't a reason to put the project in that kind of situation when GitHub can handle that for us. It also looks like the site may already be hosted through GitHub pages, which would make AWS hosting even less enticing.

[InternetPseudonym]

again : read my comment.

[johnjaylward]

again, read mine. There is no benefit to a third party hosting a project site when it can be managed free already through the existing project tools. In fact, it would make the project harder to maintain.

[arcolf]

@robertandrewbain Do you have any news on this issue? From an outsider's perspective it seems it faded away a little bit. Thanks.

[lqc]

Same here. I can devote 1day/week to help organize stuff and merge some long standing PRs, but kind of need to know what the plan is (is there any already?). The website seems like a secondary issue to me. Proving that the project is actually moving forward will attract more helpers.

[robertandrewbain]

Timo completed the handover with Ruben who is having some health issues at the moment and has gone silent. Waiting to hear from Ruben to set things up and get the ball rolling.

[InternetPseudonym]

for anyone who is interested - he is talking about this awesome guy : @Shredder121

[tpischke-bedag]

This looks to be stagnating and the slack link is dead. The current status seems to be that Ruben has no time to work on the project, and no further contributors are forthcoming, correct?

[robertandrewbain]

This looks to be stagnating and the slack link is dead. The current status seems to be that Ruben has no time to work on the project, and no further contributors are forthcoming, correct?

I agree. I'll chase this up. If @Shredder121 can't act as repo owner, someone else can. Let's move forward.

[robertandrewbain]

@tpischke-bedag thanks for the push. I'm now an owner of the repo and have got the slack channel back in action. Let's get cracking. @Shredder121 will be back in business in the coming months.

[tan31989]

Hi,
I would like to pitch in, let me know if you want any help right away.
I think QueryDSL has been a great repository to maintain and use.

[ferinoc]

Hi all,
thank you very much that you are trying to make query dsl alive again. I would like to ask when do you think you can release some stable version with support new version of spring boot? I read some threads that there is some problem with new hibernate.
I'm not very good with databases but if there is something which I can help, I can try.

[tpischke-bedag]

I've also heard that there are issues with the Hibernate 6 and QueryDSL. It seems to me that if QueryDSL is to be rescued, then these issues need to be addressed ASAP. Hoping for some start to action 'in the coming months' doesn't sound very encouraging to me. For me to continue to recommend QueryDSL to developers at my company, I would need to see some substantial code work starting immediately.

It's not out of the question that my company could contribute to the project, but right now it's not entirely clear what the process for this would entail.

[kszosze]

I'm pretty happy to help with to revive this project. I used QueryDsl before and really love this idea. Count on me to help. So feel free to ping me.

[kpihlblad]

@robertandrewbain - I am happy to help and might be able to get some support from my employer - under investigation. Let me know if I can do something.

[kamko]

Is the slack community alive? (or better is anything happening?)

[robertandrewbain]

Is the slack community alive? (or better is anything happening?)

In short, not really. I led this push because I thought there was a chance of getting the project active but offered little myself. I thought perhaps the open-source community would be excited to move it on but I guess like me, everyone has full-time dev jobs and lives outside that.

AFAIK, Timo worked for Mysema who built QueryDSL for their internal projects and Timo open-sourced it. He stopped working there and everything ground to a halt. We got a few keen people interested in helping but it's just too much work without getting paid.

I'm afraid to say, IMO, it's dead. Use JOOQ.

[robertandrewbain]

With that said, my company (I'm an employee) uses querydsl-sql extensively and I've looked at ripping out all other dependencies and upgrading to Java 12 and it's straightforward. I don't want to come to the point where a Java version upgrade causes issues so I'm looking to get on this. Happy to make this available for others but I think querydsl-jpa is very popular too and I'm not looking at touching that.

[kamko]

All right, that's a bit sad but understandable. A lot of baggage pilled up after the project halted so getting it alive would require too much time and java community is not really that into OS.

Anyways, thanks for trying.

Shouldn't we at least add some notice to the readme stating that it's not actively maintained anymore?

[robertandrewbain]

All right, that's a bit sad but understandable. A lot of baggage pilled up after the project halted so getting it alive would require too much time and java community is not really that into OS.

Anyways, thanks for trying.

Shouldn't we at least add some notice to the readme to state that it's not actively maintained anymore?

I think that we should. @Shredder121 etc. may not agree but it's been years now and it's wasting people's time raising issues etc.

I'll put it out there on the slack channel and provide an update.

[tpischke-bedag]

I agree. Adding a statement that it is no longer maintained may raise awareness and inspire a fork. Who knows?

[tpischke-bedag]

For the record, I think if the SQL and JPA Modules were rescued, that would suffice for QueryDSL to remain relevant. Since jOOQ is only Open-Source for OS DBs, QueryDSL still has a lot of appeal to companies using SQL Server, Oracle, etc.

[kszosze]

I think we can get a small amount of volunteers and keep this proyect alive, since people still commiting cod there are almost 53 PR to be merged.. may be not handle all reported issues, but address small amount of(critical ones, update to latest java versions... ) I believe is doable.

[entonio]

My unsolicited advice is that the project is put in strict maintenance mode - do what's needed for it to work with modern JDKs and frameworks like Spring (maybe reduce dependencies to avoid versioning problems). It's not like it doesn't do enough things already. It doesn't need new features or neat refactorings, it just needs to be compatible with the others things people have to use.
If it all hangs on compatibility with the latest Hibernate and that would need massive changes... then forget what I said.

[idosal]

While Robert is right about time limitations, one of the major hurdles was that the handover wasn't complete. This issue was resolved, and we're now taking active measures to get this rolling. We'll soon release a plan in accordance with the community discussion on Slack.
Naturally, we'd appreciate community feedback and contributions as we move forward. Don't give up just yet. :)

[kamko]

Is there a way to join the slack workspace?

[idosal]

The Slack channel was set up to get the handover off the ground. As such, it's no longer active. I think we should keep future discussions on Github for the time being.

[kamko]

All right then, waiting for updates.

[robertandrewbain]

I'm afraid to say, IMO, it's dead. Use JOOQ.

My pessimism was hasty. The life or death talks on here have got the cogs moving. There's life in the old dog yet. Existing team member from the old-school, John Tims, is getting the new team off the ground and putting the project in good order to create a fresh starting point. This is where we're at, release coming soon. https://github.com/querydsl/querydsl/projects/2

[robertandrewbain]

For the record, I think if the SQL and JPA Modules were rescued, that would suffice for QueryDSL to remain relevant. Since jOOQ is only Open-Source for OS DBs, QueryDSL still has a lot of appeal to companies using SQL Server, Oracle, etc.

100% agree, I said this from the outset. https://stackoverflow.com/questions/55668960/whats-the-latest-status-of-querydsl/56029689#56029689 Discussions on the slack workspace for the handover didn't align with this view. Talk is cheap, though.

The reality is, if querydsl is slim with a reliable automated build and release process, the project is back in action. And that's what we're doing.

[InternetPseudonym]

My unsolicited advice is that the project is put in strict maintenance mode - do what's needed for it to work with modern JDKs and frameworks like Spring (maybe reduce dependencies to avoid versioning problems). It's not like it doesn't do enough things already. It doesn't need new features or neat refactorings, it just needs to be compatible with the others things people have to use.
If it all hangs on compatibility with the latest Hibernate and that would need massive changes... then forget what I said.

this. PLEASE focus on bugs & maintenance - its much more important to keep QueryDSL alive and well. Reduce everything to its core over time, eliminate all the bugs and keep it up to date - thats how actual industry standards are made. The world needs you, guys, dont let feature-creep kill all of this, we've got something awesome right here

[lukaseder]

My pessimism was hasty. The life or death talks on here have got the cogs moving. There's life in the old dog yet. Existing team member from the old-school, John Tims, is getting the new team off the ground and putting the project in good order to create a fresh starting point. This is where we're at, release coming soon. https://github.com/querydsl/querydsl/projects/2

If it helps, this pessimism even happens to me from time to time. That's perfectly normal 😉. Keep it up!

[ferinoc]

would be possible to contact pivotal and offer them ownership? Don't have direct contact to them but may be they will be interested. Just not sure how it is with ownership.

[robertandrewbain]

would be possible to contact pivotal and offer them ownership? Don't have direct contact to them but may be they will be interested. Just not sure how it is with ownership.

I emailed Oliver Gierke back at the start of the crusade to see what his views were and he didn't respond. We've got a small team who are putting the project in good shape and starting to perform releases. That's all we need.

[MystereJack]

Hey guys,
I think the first goal has to be compatibility with Hibernate 5.X. For our company, it's the only thing who pushed us right to CriteriaAPI and its horrible syntax.

I'm ready to help if you need some, feel free to contact me !

Keep it up, guys !

[idosal]

Hey guys,
I think the first goal has to be compatibility with Hibernate 5.X. For our company, it's the only thing who pushed us right to CriteriaAPI and its horrible syntax.

I'm ready to help if you need some, feel free to contact me !

Keep it up, guys !

Rest assured that compatibility issues are a top priority for 5.0. We were actually wondering if Hibernate compatibility was still a problem. A few of us running Querydsl-JPA with Spring Boot 2.1.3 (Hibernate 5.3.7) and haven't run into any trouble. Could you please be more specific as to what compatibility issues you face?

[MystereJack]

Rest assured that compatibility issues are a top priority for 5.0. We were actually wondering if Hibernate compatibility was still a problem. A few of us running Querydsl-JPA with Spring Boot 2.1.3 (Hibernate 5.3.7) and haven't run into any trouble. Could you please be more specific as to what compatibility issues you face?

Good to know that compatibility issues are a top priority !
At the beginning of the year, I did a trial with Hibernate 5 which didn't work very well but I can't, right now, explain you in details why because I no longer have this environment up.

We'll start a full migration in early 2020 and I could be more specific at this moment. Be sure that I'll give you all details then.

[rjricken]

Hey guys,
I think the first goal has to be compatibility with Hibernate 5.X. For our company, it's the only thing who pushed us right to CriteriaAPI and its horrible syntax.
I'm ready to help if you need some, feel free to contact me !
Keep it up, guys !

Rest assured that compatibility issues are a top priority for 5.0. We were actually wondering if Hibernate compatibility was still a problem. A few of us running Querydsl-JPA with Spring Boot 2.1.3 (Hibernate 5.3.7) and haven't run into any trouble. Could you please be more specific as to what compatibility issues you face?

I'm sure there are several other ways to reproduce and better characterize the compatibility issues with Hibernate 5.3+, but a simple way of demonstrating the issue with positional parameters can be seen in this Gist (the same query works just fine with JPAquery.)

Hibernate 5.3 migration guide explains the changes in more details for those interested. Also, this issue discusses the problem and is still relevant.

PS: Hibernate 5.1 introduced unintended binary compatibility issues, but those were fixed in 5.3.

With that being said, I am very interested in having those fixed and I'm willing to contribute whenever help is needed. Like others said, this is a major issue to our company as well.

[idosal]

Thank you both for the answers. So, if I understand correctly, the remaining compatibility issue is positional params. Does that mean the issues described here were solved with Hibernate 5.3?

[rjricken]

Thank you both for the answers. So, if I understand correctly, the remaining compatibility issue is positional params. Does that mean the issues described here were solved with Hibernate 5.3?

The PR you mention attempts to fix https://github.com/querydsl/querydsl/issues/1917 and https://github.com/querydsl/querydsl/issues/2264. https://github.com/querydsl/querydsl/issues/1917 is fixed in Hibernate 5.3. Not sure about https://github.com/querydsl/querydsl/issues/2264.

[odrotbohm]

Speaking from a Pivotal point of view we're certainly interested in seeing Querydsl being maintained, even if it is for only maintenance work like supporting current JDKs, fixing bugs etc. That said, I don't think I can make a case here internally to own this but we're of course happy to contribute.

I think what's crucial is to find someone who's able to actually perform releases and merge pull requests as enthusiasm for contribution is usually declining quickly if you have your PRs sitting (un)merged for quite a while. Actually merging changes probably requires someone with deeper insight into the codebase in the first place.

Querydsl has several sub-projects with different activity. My feeling is that the project should be divided to separate projects to let separate communities work on them. E.g.: One who contributes querydsl-sql might not be interested in querydsl-jpa and vice-versa.

The separation and different versioning would help coming out with bugfix versions for the separate modules much faster.

I'd vote against both splitting up the project and removing modules at least in the immediate future. The suggestion strongly underassumes the amount of work and coordination it requires to change modules in a backwards compatible manner and how easy it is to break things as soon as you don't get immediate feedback. Also, the breadth of supported stores was one of the reasons we were considering Querydsl for integration into Spring Data in the first place. If that aspect is reduced, that makes Querydsl less attractive for us and I guess we're a pretty prominent usage driver of the project in the first place.

Individual releases also place a lot more burden on the user as they'll have to find out about compatible versions for the modules they're interested in. Right now, you need to know a single version number plus the leaf module you're interested in. That's great.

If someone is interested in contributing in a particular module only, they're free to do so, even with the current arrangement.

[robertandrewbain]

I think what's crucial is to find someone who's able to actually perform releases and merge pull requests as enthusiasm for contribution is usually declining quickly if you have your PRs sitting (un)merged for quite a while.

100% agreed and the Querydsl team are on it with our November release demonstrating that things are very much back in action.

the breadth of supported stores was one of the reasons we were considering Querydsl for integration into Spring Data in the first place. If that aspect is reduced, that makes Querydsl less attractive for us and I guess we're a pretty prominent usage driver of the project in the first place.

This is an extremely important point. Distancing Querydsl from Spring would be a massive act of self-harm and something we will avoid at all costs.

I'd vote against both splitting up the project and removing modules at least in the immediate future.

Querydsl was unmaintained for a long time. There's interest from the OS community now things are up and running but devs have full-time jobs too. If we can lose weight while maintaining support for all dependant spring modules, as well as other popular modules, we should do it.

E.G. I don't imagine Spring uses:

• querydsl-collections
• querydsl-hibernate-search
• querydsl-jdo
• querydsl-lucene*
• querydsl-mongodb
• querydsl-scala
• querydsl-spatial
• querydsl-sql-spatial

@odrotbohm if you have the time, it would be extremely helpful if you could let us know which of the above modules we could drop without impacting Spring integrations/interest from Pivotal.

[odrotbohm]

We definitely build on querydsl-mongodb and I'd also love to see querydsl-collections stay around as it's a nice little helper to verify ones criteria based on some collection of dummy data rather than actually querying the database.

Maybe a path forward for a 5.0 is to simply exclude a couple of the modules from the set of artifacts shipped with a release (through simple build means) and then see how an M1 is perceived. If people complain right away you ca re-add them in a later milestone or even in a 5.1.

[eXsio]

My heart grows bigger and bigger while I follow this thread. I've already lost my hope of seeing this project alive.

I for one hope that not only the JPA module will be actively developed, but also the SQL one.

I think QueryDSL has a huge potential and to prove it, I've just released brand new tool that is based on the SQL module: https://github.com/eXsio/querydsl-entityql

I would also gladly contribute to that module if there would be some dev guide so that I don't have to discover everything by reading through the code.

As for separating the modules I think you guys should at least consider moving to JIRA and creating separate backlogs for each module.

GitHub is not a good place to handle all issues from all modules in one bag.

[robertandrewbain]

As for separating the modules

There's no plan to separate the modules.

I for one hope that not only the JPA module will be actively developed, but also the SQL one.

We can 100% guarantee that querydsl-sql will continue to be developed.

[eXsio]

There's no plan to separate the modules.

Understandable, but separating backlogs would still be a nice and pro-producive move :)

[robertandrewbain]

@eXsio querydsl-entityql looks excellent - you've devoted a lot of expertise, time and effort into it. You have some strong opinions on the direction of querydsl because you're working closely with it and want it to succeed. Would you consider joining the team and having a place at the table? Querydsl was unmaintained for 2 years. We have a core team that have WD40ed the rust off and streamlined the release process but we need more.

[eXsio]

@robertandrewbain Thank you for your kind words. It is true that I'm working with the SQL module for some time now and would like it to succeed. I am also using EntityQL for various projects and I see the potential of being able to utilize advantages of both JPA and SQL worlds.

To answer your question, I would very much like to join the team and help to lead QueryDSL into the future :) As most of us (if not all) I too have my professional job and a family to take care of in the first place, but I would be glad to be able to contribute as much as I can in my free time.

[robertandrewbain]

To answer your question, I would very much like to join the team and help to lead QueryDSL into the future :)

@eXsio I've invited you to the team Slack channel using your github email address.

[robertandrewbain]

@odrotbohm we're very grateful for your input. Your experience and track record for creating and maintaining APIs is world-class.

The suggestion strongly underassumes the amount of work and coordination it requires to change modules in a backwards compatible manner and how easy it is to break things as soon as you don't get immediate feedback.

Individual releases also place a lot more burden on the user as they'll have to find out about compatible versions for the modules they're interested in. Right now, you need to know a single version number plus the leaf module you're interested in. That's great.

These are excellent points. Keep it simple, one version that "just works" - the project is small enough that this is workable.

@odrotbohm I know that Pivotal can't make a case for getting super-involved but how would you feel about being invited to the team Slack channel? We have a team of experienced developers but none of us have your background in API provision. My thought was that you could dip in and out and provide guidance on where we're moving functionally and structurally, and keep us in alignment with Spring, which is where we need to be to create a long-term positive outcome for the project.

[jwgmeligmeyling]

I'm saddened to see that this project has been unmaintained for so long. True story is that the project is just of such remarkable quality. I have been using QueryDSL 3 and 4 for years now and I've rarely found the need to visit the issue tracker here. Hence I must have missed the news. Great job at keeping it alive!

That said, from looking at the Github network dependents (that only looks at public repositories) querydsl-mongodb is actually fairly popular - in particular in Spring Boot applications: https://github.com/querydsl/querydsl/network/dependents?package_id=UGFja2FnZS0xODE0Njc0MzI%3D . Removing this module may cause some back lash (perhaps a good way to lure end users to the repository/issue tracker though 😉 )

Personally I use querydsl-spatial quite extensively. As spatial extensions are quite specialised I think the use of this artefact may go largely unnoticed. I know that hibernate-spatial is used quite a bit. I would be interested in helping with maintaining it, however if its really a burden on the rest of the development of QueryDSL it also lends itself well to be maintained elsewhere in a separate repository.

What perhaps should be considered is that querydsl-spatial is the only module that can be considered an extension to QueryDSL. Its approach can be reapplied by end users to implement custom expression types (and code generation for it), which is useful in applications that rely heavily on custom types (which becomes increasingly important as JPA/JDBC libraries get behind the possibilities within the JDK/ecosystem). From an extendability and compatibility point of view I think it might be beneficial to keep this module alive as well.

[idosal]

@jwgmeligmeyling Mongo does seem to be relatively popular (and relevant to our integrations), and as such will be moving forward. In any case, we'll make an effort to carry most modules with us to 5.0.
Specialized modules like Spatial will probably be better maintained by their users. We'd be happy to merge contributions, starting with your recent PR. :)

[idosal]

@rjricken @MystereJack The Hibernate compatibility issue is fixed in #2354. It will be featured in the next official release, which will also remove support for Hibernate 4. For now, you can try it out in 4.2.3-SNAPSHOT. I'd appreciate your feedback. Thanks!

[entonio]

Thank you very much for keeping this project alive and relevant.
Tho I've been following this thread over the months, there are a couple of things that are not immediately clear to me and I think they would merit a mention on the front page. I apologise beforehand if the information is easy to see, if so I missed it, wouldn't be the first time. So:

• More or less, when is the first 'after resumption' release to be expected?
• Is there a way to make querydsl work with a gradle that supports Java 10+?
• Is there a way to make querydsl accept a newer guava, which is required by a number of other libs?
• Are these or other points in need of specific help? I mean things where you know and can explain what needs to be done, but have no time to do it yourselves.

Thanks!

[idosal]

@entonio Thanks for the feedback. I’m glad to see your enthusiasm and we’re always happy for contributions.

• We’ve actually already released 2 versions. Our recent release of 4.3 introduced several fixes, including extensibility features, Hibernate 5 compatibility and minor bug fixes. 4.2.2 was a release to test the new automated release process. We’re gearing up towards Querydsl 5.0, but we still have some tasks to finish.
• Is there a problem now? Some of us are using Java 11+ without issues.
• Yes, you can force a more recent version of Guava if needed. I gather you’re using Gradle, so you can use the method I explained here.
• We have a board for 5.X. Feel free to take up any of the open tasks (let us know as to avoid time waste). Obviously any fixes to open Issues would be welcome.

[maikebertpsc]

@idosal May I ask why I don't see any 4.3 tags in the repository?

[entonio]

@idosal I apologise for the delay.
The last release or tag I see is 4.2.2, from November. I was wondering if development had moved elsewhere.
The gradle integration was not compatible with gradle 5, and in turn gradle 4 is not very compatible (or at all) with Java 10+, due to the way it reads the version number. But as I haven't tested a newer release, I can't say.
As to the rest, thank you for the pointers, I'll be watching the board for things I may be able to do.

[idosal]

@maikebertpsc You're right, the tags haven't been set, although the new versions have been released to maven and are available for use since we announced them. We'll take care of the tags ASAP.
@entonio Do you mean the old plugin? You should directly add the Querydsl dependencies in build.gradle instead (with version 4.3.1). There are a few relevant Stackoverflow posts and Issues hanging about. Let us know if you need further assistance.

[latuszek]

@idosal where the new versions have been announced (besides maven repo)? I'm asking because I cannot find the information and I'm interested in what has been changed in those releases.
The newest reference documentation on the official website is for 4.1.2 version, do you plan to update the website?

[idosal]

@latuszek Unfortunately, they haven't been properly announced (mostly in relevant issues or here). In any case, the tags have been pushed now.
The team is in the process of migrating to Github Pages, where the documentation will be maintained going forward. We'll clear things up in an announcement soon.

[completehealth]

Hi folks!

Great so see new owners and contributors to keep this amazing project going!

We've been trying to get querydsl working with Gradle 5, we're currently on the 4.3.1 release and looks like Gradle 5+ is still not supported.

We did some research and see that there appears to be some effort to support Gradle 5, for example the following which seems to be closed. Wondering if this made it to 4.3.1 release, or are these targeted for an upcoming release?
https://github.com/ewerk/querydsl-plugin/issues/3

If its the later, is there any known workaround to get Gradle 5 working with the current querydsl version we're using?
We're research this quite a bit, and tried a couple of workarounds, without much luck.

Incredibly grateful for any insights and/or advice you may have to help us with getting querydsl to work with Gradle 5.

Thanks so much in advance!

[kwon37xi]

@completehealth if you mean querydsl jpa code generation, there is no need to use querydsl gradle plugin.
I use gradle 6.x and querydsl JPA 4.3.x with the following solution.

Please refer to http://honeymon.io/tech/2020/07/09/gradle-annotation-processor-with-querydsl.html

configure(querydslProjects) {
    apply plugin: "io.spring.dependency-management"

    dependencies {
        compile("com.querydsl:querydsl-core")
        compile("com.querydsl:querydsl-jpa")

       // I guess if you need another annotation processor just change jpa to whatever you want.
        annotationProcessor("com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jpa")
        annotationProcessor("jakarta.persistence:jakarta.persistence-api")
        annotationProcessor("jakarta.annotation:jakarta.annotation-api")
    }