main: Update plugin openapi-generator to v7.13.0

[renovate-bot]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
org.openapi.generator	7.12.0 -> 7.13.0

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

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

---

This PR was generated by Mend Renovate. View the repository job log.

[snazy]

Why is this closed?
What's the reason?

I think, we should make it work, not ignore the bump.

[eric-maynard]

We’re standardizing on 7.11 elsewhere such as the Python client, and it became pretty clear during that work that continuing to bump the generator is likely to introduce breaking changes without much apparent value. If you see value in bumping a particular dependency, you can always open a PR to do so.

…

On Fri, Jun 13, 2025 at 11:53 AM Robert Stupp ***@***.***> wrote: *snazy* left a comment (apache/polaris#1796) <#1796 (comment)> Why is this closed? What's the reason? I think, we should make it work, not ignore the bump. — Reply to this email directly, view it on GitHub <#1796 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFRE3SFV5GMNNSUHHLWDO7T3DMM4NAVCNFSM6AAAAAB6PENO3SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNZRGMZDMNBYGA> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[dimas-b]

We’re standardizing on 7.11 elsewhere [...]

As far as Polaris is concerned, I believe this needs a dev email discussion (I might have missed it if it happened, but I do not recall this discussion).

[snazy]

We’re standardizing on 7.11 elsewhere [...]

As far as Polaris is concerned, I believe this needs a dev email discussion (I might have missed it if it happened, but I do not recall this discussion).

Yea - I am not aware of such a decision in the Apache Polaris project. Do you have a reference?

[eric-maynard]

I'm confused what the issue is here. Nothing is stopping anybody from updating a dependency, but how long should we keep an automated PR that's failing CI and creating divergence in the generator used by different parts of the repo open? It was already some two weeks old when I closed it.

Is there a reference to some point in time where there was agreement to always keep this dependency up to date? To keep these PRs open indefinitely?

[flyrain]

We cannot upgrade to 7.13 due to this issue, #1822.

[dimas-b]

@eric-maynard : from my POV the issue is merely the word "standardizing", which you had in an earlier comment. If we're standardizing on anything, I think that needs a dev email discussion. GH comments are not visible enough for that purpose, IMHO.

[dimas-b]

@flyrain :

We cannot upgrade to 7.13 due to this issue, #1822.

#1822 is marked as "fixed" by #1823. Could you clarify why it is (still) a problem for upgrading the generator tool?

[HonahX]

Hi guys, I would like to bring more context here.

The issue with the open-api-generator for python client, as documented here: #1822, makes it necessary to use version 7.11 to fix all the compatibility issues with other dependencies and python versions. In other words, we are stuck on open-api-generator 7.11 for python now.

If open-api-generator community releases a newer version that fix all the compatibility issues, we will be unblocked from upgrading the generator used for python client.

So overall it is mainly the breaking changes/technical issues that preventing us from upgrading. I think we could have issue/PRs to track the breaking changes in new dependency versions. IMHO, closing this auto-generated PR will help clarify that we need a manual fix for this version bump.

[eric-maynard]

Hey Dmitri, apologies if that wording was not the best. That standardization is happening in code.

For example, I would say that we have standardized on using the name LOGGER for logger objects. We've standardized on a sort of 3-level structure for catalogs (Adapter, Handler, Catalog). Sometimes these patterns emerge in the code without an explicit discussion on the topic, and they're bound to change as needs shift.

In the case of the generator, I only meant that we've recently upgraded to 7.11 for the Python client but weren't able to upgrade further at that point in time. Jonas's comment has some details on this. We may be pinned on 7.11 for a while, and I saw that there could be value in aligning this with the rest of the project.

If we want to use different versions of the generator for different parts of the code that's totally fine. However when I saw this PR that was:

1. Automated, i.e. without a human owner
2. Old without any community engagement
3. Failing tests
4. Contrary to the trend / "standardization" I mentioned for the Python client

I closed it to cut down on the number of open PRs, figuring that we'd reopen it if a good reason to do the upgrade arose at some point down the road. Sorry for any confusion.

[flyrain]

We cannot upgrade to 7.13 due to this issue, #1822.

#1822 is marked as "fixed" by #1823. Could you clarify why it is (still) a problem for upgrading the generator tool?

The #1823 resolved it by enforcing the version 7.11.

[dimas-b]

Thanks for the background, @flyrain @eric-maynard @HonahX !

What is still unclear from my POV is that this PR changes only gradle/libs.versions.toml, while #1823 does not touch this file. At the same time this PR does not touch client/python/.openapi-generator/VERSION, which is modified by #1823.

My reading is that we already have isolation of openapi-generator usage between java code and python code.

I do not have any objections to keeping the python side on an older version of the generator until technical roadblocks are removed.

I wonder, though, if we could upgrade the java side independently 🤔 WDYT?

[dimas-b]

If the upgrade is problematic - no objections from my side to closing this PR :)

[eric-maynard]

+1, if this PR can be made to work and the general sentiment is we want to keep upgrading this on the Java side even if Python is pinned, let's fix it up and keep it open.

[dimas-b]

rebased manually... IDK why Renovate would not rebase this PR 🤷

[dimas-b]

CI failures in java code look non-trivial to me. I think upgrading the API generator even for java code will require some manual work... not sure if there are any volunteers ATM 🤔