Upgrade OpenRewrite Templating 1.11.2 -> 1.12.0

[Picnic-DevPla-Bot]

This PR contains the following updates:

Package	Type	Update	Change
OpenRewrite Templating		minor	1.11.2 -> 1.12.0
OpenRewrite Templating	compile	minor	1.11.2 -> 1.12.0

---

Release Notes

openrewrite/rewrite-templating (OpenRewrite Templating)

v1.12.0: 1.12.0

Compare Source

What's Changed

• refactor: Update Gradle wrapper by @​shanman190 in https://github.com/openrewrite/rewrite-templating/pull/98
• Add "@​Generated" annotation to generated classes by @​mbruggmann in https://github.com/openrewrite/rewrite-templating/pull/97

New Contributors

• @​mbruggmann made their first contribution in https://github.com/openrewrite/rewrite-templating/pull/97

Full Changelog: openrewrite/rewrite-templating@v1.11.0...v1.12.0

---

• If you want to rebase/retry this PR, check this box

[Picnic-DevPla-Bot]

Suggested commit message:

Upgrade OpenRewrite Templating 1.11.2 -> 1.12.0 (#1252)

See:
- https://github.com/openrewrite/rewrite-templating/releases/tag/v1.12.0
- https://github.com/openrewrite/rewrite-templating/compare/v1.11.2...v1.12.0

[Stephan202]

The build failed because the generated code now references the deprecated javax.annotation.Generated annotation, rather than the javax.annotation.processing.Generated annotation introduced in JDK 9.

I worked around this by adding a legacy dependency, but @timtebeek I wonder whether it'd be possible to (conditionally?) generate code with the newer annotation. (I don't think this will worsen the status quo described in openrewrite/rewrite-third-party#11 (something I've been meaning to have a closer look at, but that's a separate topic), as Java will ignore unknown annotations at runtime.)

[github-actions]

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

[Picnic-DevPla-Bot]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠ Warning: custom changes will be lost.

[github-actions]

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[timtebeek]

The build failed because the generated code now references the deprecated javax.annotation.Generated annotation, rather than the javax.annotation.processing.Generated annotation introduced in JDK 9.

I worked around this by adding a legacy dependency, but @timtebeek I wonder whether it'd be possible to (conditionally?) generate code with the newer annotation. (I don't think this will worsen the status quo described in openrewrite/rewrite-third-party#11 (something I've been meaning to have a closer look at, but that's a separate topic), as Java will ignore unknown annotations at runtime.)

Indeed could be best to remove this requirement; for us in practice it hadn't been an issue as we pin to Java 8 for now, as much as I'd like to allow for newer constructs in our Refaster templates. Haven't explored the options on how to pass configuration into our annotation processor yet, but perhaps you have some ideas or experience there.

[Stephan202]

Haven't explored the options on how to pass configuration into our annotation processor yet, but perhaps you have some ideas or experience there.

No personal experience, but I think CheckerFramework does this as well, so that should work. (For compiler plugins one can do this and then this, but I suppose annotation processors should be preferred.)

Anyway, we merged this PR, so no urgency from our side to change this :)