Consider (additional) contribution to OpenRewrite to simplify version updates for users

[jjank]

Hi Hibernate team,

I'm an active user of the OpenRewrite-project. It is a tremendous time and quality saver when upgrading/migrating applications.

There's already detailed migration guides - that's great!

Note that the OpenRewrite-team already has some support for migrating to ORM 6.1 but in my opinion there is room for more 😁 .

One concrete example from the 6.0 migration guide - Renaming of JavaTypeDescriptor contract could be automated with the Change type recipe in OpenRewrite:

---
type: specs.openrewrite.org/v1beta/recipe
name: org.hibernate.orm.migrate
displayName: Renaming of JavaTypeDescriptor contract
recipeList:
  - org.openrewrite.java.ChangeType:
      oldFullyQualifiedTypeName: org.hibernate.type.descriptor.java.JavaTypeDescriptor
      newFullyQualifiedTypeName: org.hibernate.type.descriptor.java.JavaType
      ignoreDefinition: null

I'm sure more examples can be found and might come up in the future.

So my point of discussion is: Would you consider either contributing to the exisiting OpenRewrite recipes and/or consider publishing your own recipes in the future? I'm cc-ing Tim te Beek from the OpenRewrite team who has offered help 😄

Thank you very much for considering this!
Johannes

[timtebeek]

Thanks for opening this issue @jjank ! Chiming in here with some perspective from working on OpenRewrite at Moderne.

For those unfamiliar: OpenRewrite is a framework for large scale source code refactoring, where we aim to automate migration steps for popular frameworks and libraries, often in collaboration with the original authors and wider community. We already collaborate with the developers behind Spring, Micronaut, Quarkus and Jakarta, among others. And we also support migrations of popular logging and testing libraries, with help from the community.

Migration steps are converted into "recipes" which at times can be very elemental: update or replace a dependency, or rename a class/method/property. For such elemental steps we allow you to define those in yaml, and write tests to verify that the before and after situations match what you intended. For more complex migration steps we allow custom recipes: Java visitors that manipulate a lossless semantic tree, where you're free to make any type of change necessary. When grouped together all these individual recipes ensure users are able to migrate with ease, often directly when a new version comes out. That then helps focus development efforts on the latest version only, and the upgrade path to get users there.

What we could do for Hibernate is extract the existing Hibernate 6.x migration recipes out into a dedicated module under github.com/openrewrite/rewrite-hibernate, and grant access to the team to collaborate on migration recipes for Hibernate there. We'll then help document & distribute these recipes. We could even do this if it's only the wider community that would like to contribute (for now), but it helps to have you all involved however that might be.

Feel free to let me know if any of this appeals to you; we really hope to work together to automate these migrations for your users.

[sebersole]

That's a great idea! I do not have any experience with OpenRewrite but would definitely help as I can

[timtebeek]

Great to hear! I've gone ahead and created https://github.com/openrewrite/rewrite-hibernate, and invited you on as a maintainer there. No worries if you don't know OpenRewrite (yet), we'll get to that as we go. If you want to explore by yourself we have documentation up on https://docs.openrewrite.org/authoring-recipes, and if you have any questions we have various channels for communication; of which Slack is most common.

I'll go ahead and migrate over the relevant community suggested recipes, and see what I can get to already. I look forward to working together!

[yrodiere]

@sebersole FYI Quarkus also uses OpenRewrite for the Quarkus 2 -> 3 (and thus ORM 5 -> 6) upgrade. I don't know where that code is nor how advanced the ORM 5 -> 6 upgrade automation is, though. @gsmet probably knows where to find that code.