Skip to content

OpenApi 3.1.2 (Fixes #728)#730

Merged
SentryMan merged 21 commits into
avaje:masterfrom
re-thc:openapi
Jul 6, 2026
Merged

OpenApi 3.1.2 (Fixes #728)#730
SentryMan merged 21 commits into
avaje:masterfrom
re-thc:openapi

Conversation

@re-thc

@re-thc re-thc commented Feb 20, 2026

Copy link
Copy Markdown
Contributor

OpenApi 3.1.2 (Fixes #728)

As per the comment this is a "just do it" version. I'll leave the major version handling for another more knowledgeable.

@re-thc

re-thc commented Feb 20, 2026

Copy link
Copy Markdown
Contributor Author

Doesn't look like this change broke CI. Edit: maybe due to caching (since this drops oai 3.0. old things would break). Edit 2: dirty file locally :(

@mechite

mechite commented Feb 20, 2026

Copy link
Copy Markdown
Contributor

Reposting test stacktrace to save the trouble:

com.fasterxml.jackson.core.JsonParseException: 
Unexpected character ('}' (code 125)): was expecting double-quote to start field name
 at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 50, column: 9]
at com.fasterxml.jackson.core.JsonParser._constructReadException(JsonParser.java:2675)
at com.fasterxml.jackson.core.base.ParserMinimalBase._reportUnexpectedChar(ParserMinimalBase.java:743)
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._handleOddName(UTF8StreamJsonParser.java:2103)
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._parseName(UTF8StreamJsonParser.java:1753)
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.nextFieldName(UTF8StreamJsonParser.java:1040)
at com.fasterxml.jackson.databind.deser.std.BaseNodeDeserializer._deserializeContainerNoRecursion(JsonNodeDeserializer.java:538)
at com.fasterxml.jackson.databind.deser.std.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:99)
at com.fasterxml.jackson.databind.deser.std.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:24)
at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:342)
at com.fasterxml.jackson.databind.ObjectMapper._readTreeAndClose(ObjectMapper.java:5094)
at com.fasterxml.jackson.databind.ObjectMapper.readTree(ObjectMapper.java:3382)
at io.avaje.http.generator.VertxProcessorTest.runAnnotationProcessor(VertxProcessorTest.java:130)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)

@re-thc

re-thc commented Feb 20, 2026

Copy link
Copy Markdown
Contributor Author

Reposting test stacktrace to save the trouble:

com.fasterxml.jackson.core.JsonParseException: 
Unexpected character ('}' (code 125)): was expecting double-quote to start field name
 at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 50, column: 9]
at com.fasterxml.jackson.core.JsonParser._constructReadException(JsonParser.java:2675)
at com.fasterxml.jackson.core.base.ParserMinimalBase._reportUnexpectedChar(ParserMinimalBase.java:743)
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._handleOddName(UTF8StreamJsonParser.java:2103)
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._parseName(UTF8StreamJsonParser.java:1753)
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.nextFieldName(UTF8StreamJsonParser.java:1040)
at com.fasterxml.jackson.databind.deser.std.BaseNodeDeserializer._deserializeContainerNoRecursion(JsonNodeDeserializer.java:538)
at com.fasterxml.jackson.databind.deser.std.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:99)
at com.fasterxml.jackson.databind.deser.std.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:24)
at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:342)
at com.fasterxml.jackson.databind.ObjectMapper._readTreeAndClose(ObjectMapper.java:5094)
at com.fasterxml.jackson.databind.ObjectMapper.readTree(ObjectMapper.java:3382)
at io.avaje.http.generator.VertxProcessorTest.runAnnotationProcessor(VertxProcessorTest.java:130)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)

Fixed

@rbygrave

rbygrave commented Mar 2, 2026

Copy link
Copy Markdown
Contributor

So for myself I'm good with this PR. So I think the steps to are something like:

  • Confirm @SentryMan is happy with this PR / change
  • Get 3.8 released shortly (without this PR, we've just released 3.8-RC4)
  • Merge this PR, and bump to 4.0-RC1

@SentryMan

Copy link
Copy Markdown
Collaborator

The only thing is how the other nullability PR is affected by this

@re-thc

re-thc commented Mar 2, 2026

Copy link
Copy Markdown
Contributor Author

The only thing is how the other nullability PR is affected by this

It's either this 1st and update or that 1st and update. Take your pick :). Maybe base it on which direction is easier.

@rbygrave

Copy link
Copy Markdown
Contributor

I think the plan should be:

  • Release 3.8
  • Bump to 4.0-SNAPSHOT
  • Merge this PR (maybe release as a RC?)
  • Update the null handling PR and look to merge that
  • Release a 4.0-RC release

@SentryMan

Copy link
Copy Markdown
Collaborator

I think the plan should be:

You could also go the other way and

Merge the null handling PR
Release 3.8
Merge this PR (maybe release as a RC?)
Release a 4.0-RC release

@rbygrave

Copy link
Copy Markdown
Contributor

You could also go the other way and

Yup, I'm good with that.

cbarlin added a commit to cbarlin/avaje-http that referenced this pull request Apr 1, 2026
Based on the discussion in avaje#743, there was mixed feelings on the shading being done for the generators. I figured since there is a major version on the horizon (based on discussions in avaje#730), what we could do is:
 * Isolate out the prism generation, to help ensure we don't end up with unintentional dependencies in the actual generators (since the generator would fail compilation in this repo if you tried)
 * Make the "main" versions of the processors no longer shaded
 * Publish separate "-shaded" versions of the generators that are shaded

The idea being if you are using `proc=full` and/or having issues with the dependencies for the generator not coming through, you can use the `-shaded` versions (e.g. instead of `avaje-http-client-generator` you'd use `avaje-http-client-generator-shaded`). If (or when) shading becomes problematic, then we can easily remove those shaded versions from being published.

There's not really a "solid reason" for doing this now rather than waiting to see what happens with `proc=full`. It's just something that was discussed, and could be added to the list of potentially breaking changes in that next major.

During this though, I did notice a couple of things:
 * The test pipeline doesn't test on Java 11, despite that being the minimum (?) Java version
 * The main `http-api` has a dependency on the `http-inject-plugin` which has a dependency back on the `http-api` and also only builds on Java 21+ (while `http-api` will try to build on Java 11)
 * The `http-api` had a (`static`/`optional`) dependency on javalin, but there's a `http-api-javalin` that could house it and forward on the `http-api` dependency
 * Both Avaje SPI and Avaje Prisms publish their annotations depending on their processor, rather than the other way around, which seems incorrect. I'm not sure if Maven 4 will have a problem with the annotations being `jar` and the dependency being `processor`. You can't have the annotations as both since duplicate G/A/V is not permitted, but even if it doesn't it "feels like" it should be the reverse (processor depends on annotations)

I've marked this as draft/rfc because I want to know:
 * Is the separate shaded versions an OK compromise?
 * Is there a preferred path for dealing with the circular dependency?

I also haven't finished:
  * all the shaded versions,
  * patching the tests so they use a mix of non-shaded and shaded generators (so we can be sure we don't break the shaded versions)
  * testing the Java 11 addition to the build process

 But I figured I'd wait for the discussion before doing too much more.
@rbygrave

rbygrave commented May 2, 2026

Copy link
Copy Markdown
Contributor

@re-thc I just resolved some merge conflicts and I would like you to have a look over those commits.

It looked like a relatively simple conflict resolution, but then I make some mistakes and then later hit some failing tests and had to adjust test expectations for everything to pass. It looks ok but if you can review those commits some time that would be great - thanks !!

@re-thc

re-thc commented May 8, 2026

Copy link
Copy Markdown
Contributor Author

@rbygrave took a look along with the null changes

@rbygrave

Copy link
Copy Markdown
Contributor

@copilot resolve the merge conflicts in this pull request

@rbygrave rbygrave requested review from SentryMan and rbygrave July 6, 2026 11:23
@SentryMan SentryMan enabled auto-merge (squash) July 6, 2026 14:23
@SentryMan SentryMan merged commit 35d0c27 into avaje:master Jul 6, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

OpenApi 3.1

4 participants