Querydsl: Breaking API change in Querydsl 4.3.0's APT module: constructor parameter of DefaultConfiguration changed

[odrotbohm]

This commit incompatibly changed the constructor of DefaultConfiguration so that existing code will neither compile correctly against that class nor can use the class in Querydsl 4.3 at runtime. This prevents Spring Data MongoDB and its users from upgrading to that version.

Would you mind re-introducing the former constructor variant?

[jwgmeligmeyling]

We can add an alias for the old constructor indeed.

But I don't get why you would users integrate with the APT internals? They are not exactly API :) Does Spring Data MongoDB ship with its own APT extension?

[kamko]

@jwgmeligmeyling
see
https://github.com/spring-projects/spring-data-mongodb/blob/master/spring-data-mongodb/src/main/java/org/springframework/data/mongodb/repository/support/MongoAnnotationProcessor.java

[odrotbohm]

Yes we do, as we need to make the Querydsl APT pick up classes with a Spring Data specific annotation (@Document) and also flip a default in configuration (see MongoAnnotationProcessor).

My Point being: breaking API changes are a big nono if you want to make sure people really use a library. I can raise the dependency version to 4.3 for Spring Data MongoDB but with that, I am forcing all users to upgrade, which might have unanticipated side effects that I cannot forsee and people are not used to that when they upgrade to a new minor version of a Spring library. They might be able or even need to downgrade to a Querydsl 4.2.x but all of this is stuff we somehow need to communicate and I'd like to avoid that. I don't want to start mixing different versions in terms of "that's what we use to compile our APT", "that's what we recommend to use at runtime etc.".

Are you actually publishing CI snapshots again? We used to point to the snapshots of upcoming versions and run our CI against those to catch stuff like that as early as possible. With the development here taking up some pace again it might make sense to revive that practice.

[jwgmeligmeyling]

I understand your point. I am not sure whether the APT module was ever considered an API, but apparently it's used as such and I am personally interested in making the APT more extensible as well. So don't get me wrong, I absolutely encourage the existence of the MongoAnnotationProcessor.

The change mentioned by the way will make it possible for ServerProviders to hook onto the APT process and bind custom types that need the ProcessingEnvironment. Therefore QueryDSL can be extended with for example custom expression types for custom types, without needing yet another AbstractAnnotationProcessor subclass.

It doesn't seem like a lot of trouble to add a constructor alias and maintain binary compatibility, so I'll create a PR for that. I am not sure what the schedule will be though for releasing it. The team still seems pretty much in startup phase. There's lots of abandoned PRs and issues here still.

In the mean time you might want to do a constructor lookup with reflection for either scenario. The parameters for either of the signatures are readily available at your point of construction.

[idosal]

@odrotbohm Thanks for bringing this to our attention. We'll restore compatibility ASAP and be sure to keep these considerations in mind in the future.
We still release snapshots, so this makes a lot of sense.

@jwgmeligmeyling The PR has been reviewed. The release process has undergone a major facelift, but it is not yet fully automated. As such, it might take a few days to be published.

[odrotbohm]

Thanks for the fast responses everyone! Is there a rough ETA on 4.3.1? We have an RC coming up March 31st and wonder whether we could wait to just upgrade to that?

[idosal]

@odrotbohm Just released 4.3.1 thanks to @johnktims. Note that we also published 4.3.2-SNAPSHOT, and will continue to do so automatically on merges to master.

[odrotbohm]

Lovely, folks. Thanks again for reacting so fast. We shipped the latest Spring Data releases with upgrades to 4.3.1.