OpenAPITools / openapi-generator

OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
https://openapi-generator.tech
Apache License 2.0
20.6k stars 6.29k forks source link

[REQ] [Java] Support of JakartaEE 9 #13124

Open RomainPruvostMHH opened 1 year ago

RomainPruvostMHH commented 1 year ago

Context

Since Eclipse Foundation is in charge of JakartaEE specifications, it's time to switch to JakartaEE 9 for openapi generator. The first step was to switch to JakartaEE 8 (see the issue #10504). It's done now.

The next step is to upgrade to JakartaEE 9 which means to upgrade to new versions of jakarta's dependencies. But this upgrade is a bit more difficult than the previous because the main goal of JakartaEE 9 is that the javax. packages to jakarta. packages have been renamed by Eclipse. I think that it will be necessary to create a new property (named jakartaeeVersion=9 for example) to allow the user to generate the source code with the actual versions of jakartaEE 8 or the last versions of jakartaEE 9.

Describe the solution you'd like

We need to upgrade the following dependencies in the Maven/Gradle/Scala mustache template files. These template files are located in openapi-generator/modules/openapi-generator/src/main/resources.

jakarta.annotation:jakarta.annotation-api:1.3.5 => 2.0.0 jakarta.validation:jakarta.validation-api:2.0.2 => 3.0.0 jakarta.ws.rs:jakarta.ws.rs-api:2.1.6 => 3.0.0 jakarta.json.bind:jakarta.json.bind-api:1.0.2 => 2.0.0 jakarta.json:jakarta.json-api:1.1.6 => 2.0.0 jakarta.xml.bind:jakarta.xml.bind-api:2.3.3 => 3.0.0 jakarta.el:jakarta.el-api:3.0.3 => 4.0.0 jakarta.servlet:jakarta.servlet-api:4.0.4 => 5.0.0 jakarta.activation:jakarta.activation-api:1.2.2 => 2.0.0

The upgrade of jakarta versions will force us to replace all javax. import by jakarta. in the mustache templates.

Then, we need a new property named jakartaeeVersion to keep the generation source code as is (with the package javax. ) or to use the new jakartaEE 9 classes in the generated source code. By default, if the property didn't set, we consider that we are still on jakartaEE 8 (javax.).

Beware, some samples are dependents of Spring Boot. For them, it will be necessary to upgrade the version of spring boot parent to 3 (release in September 2022). It is not part of the scope of this issue.

How to validate the request

We need to create an unit test with the property jakartaeeVersion. The versions of depedencies should be equal to the versions above. And of course, we need to create a new java sample with the new property.

Additional context

Versions of JakartaEE 9 : https://projects.eclipse.org/releases/jakarta-ee-9. Or a map here https://jakarta.ee/release/9/ Explanations of JakartaEE 9 release plan : https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan

bmarwell commented 1 year ago

This has been a request for two years now:

https://github.com/OpenAPITools/openapi-generator/issues/6881

madorb commented 1 year ago

This is a big problem now that Spring Boot 3.x / Spring Framework 6.x are released and only support Java 17 + JakartaEE 9. OpenApi generator no longer will work with any up-to-date spring apps.

PascalSchumacher commented 1 year ago

Wasn't this feature already implemented in: https://github.com/OpenAPITools/openapi-generator/pull/12407 ?

madorb commented 1 year ago

i suppose it's not clear, from the ticket - but i believe server side support has been implemented, but client generation still does not support emitting JakartaEE 9 annotations (Generated, bean validation, etc.)

arham-saeed commented 1 year ago

This is a huge blocker for migration to spring boot 3.

varminas commented 1 year ago

This is a blocker for us as well. As an option would be the usage of spring generator, but it generates Java classes which is not the aim.

SwapnilKhante commented 1 year ago

Is there a work around here?

RomainPro76 commented 1 year ago

As a workaround, you can do the following:

            <plugin>
                <groupId>org.openapitools</groupId>
                <artifactId>openapi-generator-maven-plugin</artifactId>
                <version>6.2.1</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                        <configuration>
                            <inputSpec>
                                ${project.basedir}/src/main/resources/api.yml
                            </inputSpec>
                            <generatorName>spring</generatorName>
                            <apiPackage>com.api</apiPackage>
                            <modelPackage>com.api.model</modelPackage>
                            <generateApiTests>false</generateApiTests>
                            <generateModelDocumentation>false</generateModelDocumentation>
                            <generateModelTests>false</generateModelTests>
                            <generateSupportingFiles>false</generateSupportingFiles>
                            <configOptions>
                                <interfaceOnly>true</interfaceOnly>
                                <java8>true</java8>
                                <dateLibrary>java8</dateLibrary>
                                <performBeanValidation>true</performBeanValidation>
                                <useBeanValidation>true</useBeanValidation>
                                <serializationLibrary>jackson</serializationLibrary>
                                <delegatePattern>false</delegatePattern>
                                <skipDefaultInterface>true</skipDefaultInterface>
                            </configOptions>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <!-- com.google.code.maven-replacer-plugin - Workaround : waiting for openapi-generator-maven-plugin supports jakartaEE 9. -->
            <plugin>
                <groupId>com.google.code.maven-replacer-plugin</groupId>
                <artifactId>replacer</artifactId>
                <version>1.5.3</version>
                <executions>
                    <execution>
                        <id>replace-import-javax-by-jakarta</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>replace</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <basedir>
                        ${project.build.directory}/generated-sources/openapi/src/main/java/com/api
                    </basedir>
                    <includes>
                        <include>**/*.java</include>
                    </includes>
                    <replacements>
                        <replacement>
                            <token>import javax</token>
                            <value>import jakarta</value>
                        </replacement>
                    </replacements>
                </configuration>
            </plugin>

The plugin com.google.code.maven-replacer-plugin:replacer search "import javax" strings in the generated files and replace them with "import jakarta" strings.

madorb commented 1 year ago

anyone happen to know of a similar plugin for gradle, google isn't giving me much luck

dsyer commented 1 year ago

For me the "spring" generator (6.2.1) worked with useSpringBoot3=true and no post processing. Also the "java" generator worked with library=resttemplate and useJakartaEe=true, but only if I bumped to 6.3.0-SNAPSHOT. So it would be good to have a release of 6.3.0.

yudanaz commented 1 year ago

I can confirm the "spring" generator solution, but couldn't make it work for the "java" generator (we use library= 'webclient' in our project) using 6.3.0-SNAPSHOT. I implemented a simple string replacement (javax\\. for jakarta.) in our Gradle build as a workaround. It does the job, but it's far from pretty.
This issue needs high priority due to the Spring Boot 3 release!

dsyer commented 1 year ago

For me library=webclient is broken even with Spring Boot 2.7. Don't you get a generated uncompilable ApiUtil with references to HttpServletRequest? UPDATE: that's the server, not the client. It's definitely broken though.

yudanaz commented 1 year ago

That's strange, we use generatorName = 'java' with library = 'webclient' successfully. We were using Spring Boot 2.7.5 (now 3.0.1) and still are using open-api generator version 6.2.1. UPDATE: Okay, just the Client in our case

dsyer commented 1 year ago

Another update: it works for me with just a client and Spring Boot 3. Here's the Maven config:

            <plugin>
                <groupId>org.openapitools</groupId>
                <artifactId>openapi-generator-maven-plugin</artifactId>
                <version>6.3.0-SNAPSHOT</version>
                <executions>
                    <execution>
                        <id>openapi-client</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                        <configuration>
                            <generatorName>java</generatorName>
                            <apiPackage>com.example.demo.client</apiPackage>
                            <modelPackage>com.example.demo.client</modelPackage>
                            <invokerPackage>com.example.demo.client</invokerPackage>
                            <configOptions>
                                <useJakartaEe>true</useJakartaEe>
                                <library>webclient</library>
                            </configOptions>
                        </configuration>
                    </execution>
                </executions>
                <configuration>
                    <inputSpec>${project.basedir}/openapi.yaml</inputSpec>
                    <configOptions>
                        <performBeanValidation>true</performBeanValidation>
                        <hideGenerationTimestamp>true</hideGenerationTimestamp>
                        <useBeanValidation>true</useBeanValidation>
                        <sourceFolder>src/main/java</sourceFolder>
                        <configPackage>com.example.demo.config</configPackage>
                    </configOptions>
                </configuration>
            </plugin>
boardtc commented 1 year ago

Thanks to you guys for trying to figure out workarounds for this serious unexpected blocker on moving to SpringBoot 3. My existing config uses <generatorName>html</generatorName> also, my general config options (2nd above) uses: <library>spring-mvc</library>

Do I need to use the snapshot version of the plugin? I am trying with 6.2.1 without messing with our build setup.

Trying to add to my existing execution config: `

true
</configOptions>`

also, tried adding <useSpringBoot3>true</useSpringBoot3>

I had the other options but didn't have <performBeanValidation>true</performBeanValidation>, so I added that.

With or without the latter / useSpringBoot3 I am getting:

java.lang.RuntimeException: Unknown library: spring-mvc

dsyer commented 1 year ago

I'm not sure what the "html" generator does with a "library" (it's not documented). Did it ever work? Anyway the examples above are all for the "spring" and "java" generators.

boardtc commented 1 year ago

After the spring-mvc error it actually said that the spring-boot library was available...so I updated spring-mvc to spring-boot and it passed that error and generated the 58 resources!!

But the generated file contains import javax.ws.rs.core.GenericType; not jakarta. So it's not working.

Thanks for letting me know about generatorName. We have always generated java even with that set to html! I tried replacing it with both spring and java and neither result in javax being removed.

Prior to build failure there is an info message, should I bother with it? [INFO] Environment variable JAVA_POST_PROCESS_FILE not defined so the Java code may not be properly formatted. To define it, try 'export JAVA_POST_PROCESS_FILE="/usr/local/bin/clang-format -i"' (Linux/Mac)

Testing to see if I get it working with 6.3.0-SNAPSHOT I played with my active profile in settings.xml & updating snapshotRepository in my pom.xml but nothing worked out to download 6.3.0-SNAPSHOT.

any advice is appreciated...

dsyer commented 1 year ago

My sample is here if you want to crib the pom.xml config: https://github.com/dsyer/openapi-demo. If you share your minimal sample I might be able to see what you need. UPDATE: there's a "client" branch that does "webclient" only (no server).

boardtc commented 1 year ago

Thank you!!

I see you use 6.3.0-SNAPSHOT, so that definitely needed then over 6.2.1? What did you add in your settings.xml to allow that to download?

I tried your config, I was not using the outer for spring and I moved to use the resttemplate library. My generated file does not import javax! But it does use @javax.annotation.Generated, is that wrong?

The build subsequently failed as [ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.3.0:resources (default-resources) on project ABC: filtering ...\src\main\resources\v1\gradle\wrapper\gradle-wrapper.jar to ...\target\classes\v1\gradle\wrapper\gradle-wrapper.jar failed with MalformedInputException: Input length = 1

Not sure yet if this related to the plugin.

dsyer commented 1 year ago

There's nothing in my settings.xml (AFAIK) it's all in the pom. If you read the comments above you will find that snapshots are only needed for the "java" generator.

If you are getting javax instead of jakarta namespaces then you aren't doing the same as my sample.

The thing with the gradle wrapper is weird (why is it in your classpath resources?), but looks completely unrelated to OpenAPI code generation.

boardtc commented 1 year ago

Thanks for the support!

Adding the section from your code bypassed our nexus, so I am now using 6.3.0-SNAPSHOT. It runs and no longer contains the javax annotation!!

I'm not sure what did it tbh but the snapshot version at least is needed. We did not have a separate configuration outside of the 2 execution sections so I restyled it like yours. I did not have hideGenerationTimestamp or configPackage, which I added. The resttemplate value for the library tag is new. We also have the additional:

                    <dateLibrary>java8</dateLibrary>

                    <interfaceOnly>true</interfaceOnly>

                    <skipOverwrite>false</skipOverwrite>

                    <useTags>true</useTags>

                    <generateSupportingFiles>true</generateSupportingFiles>

But I get the same MalformedInputException: Input length = 1 gradle error with maven-resources-plugin...bizarre...but the resources/v1 path shown in the message is our output tag value so anything under it is generated.

As well as pom,XML in there I see build.gradle, I assume they are in your generated output as standard also - the readme.md discusses the gradle option as well as maven. Here's what's generated in my target\generated-sources\openapi (& also in resources\v1, so despite the error the copy worked): \ image

I haven't figured out the MalformedInputException: Input length = 1 message yet but any input welcome.

It appears that gradle-wrapper.jar is not generated correctly by openapi-generator-maven-plugin? I can open the jar...

madorb commented 1 year ago

The Gradle wrapper is not generated by a maven plugin. Is your project a maven or gradle project? It seems like maven, and if so, you almost certainly want to update your .openapi-generator-ignore to cause it to not generate either the maven or gradle files.

Also then share the entirety of your <plugin> configuration as dave has above, sharing little snippets doesn't help anyone help you.

boardtc commented 1 year ago

We do not use gradle at all, it's a java project! I checked and previously the Gradle stuff was not generated!

Something must have changed in the current plugin I guess and I need a new config setting? But you say it's not generated by the generator... what else would create the folder \target\generated-sources\openapi\gradle ?

... will play with .openapi-generator-ignore but think it should not be generated if the settings are correct as @dsyer didn't use openapi-generator-ignore in his demo code

Full config UPDATED 27 Feb 23:

      <plugin>
        <groupId>org.openapitools</groupId>
        <artifactId>openapi-generator-maven-plugin</artifactId>
        <version>${version.openapi-generator-maven-plugin}</version>
        <executions>
          <execution>
            <id>openapi-server</id>
            <phase>generate-sources</phase>
            <goals>
              <goal>generate</goal>
            </goals>
            <configuration>
              <inputSpec>${project.basedir}/src/main/resources/v1/foo.yaml</inputSpec>
              <generatorName>java</generatorName>
              <output>src/main/resources/v1</output>
              <configOptions>
                <useSpringBoot3>true</useSpringBoot3>
               <useJakartaEe>true</useJakartaEe>
                <interfaceOnly>true</interfaceOnly>
              </configOptions>
            </configuration>
          </execution>
          <execution>
            <id>openapi-client</id>
            <phase>generate-sources</phase>
            <goals>
              <goal>generate</goal>
            </goals>
            <configuration>
              <generatorName>spring</generatorName>
              <modelNamePrefix>foo</modelNamePrefix>
              <configOptions>
                <library>spring-boot</library>
              </configOptions>
              <apiPackage>foo</apiPackage>
              <modelPackage>foo.model</modelPackage>
              <groupId>${project.groupId}</groupId>
              <artifactId>${project.artifactId}</artifactId>
              <artifactVersion>${project.version}</artifactVersion>
              <environmentVariables>
                <enablePostProcessFile>true</enablePostProcessFile>
              </environmentVariables>
            </configuration>
          </execution>
        </executions>
        <configuration>
          <inputSpec>${project.basedir}/src/main/resources/v1/foo.yaml</inputSpec>
          <configOptions>
            <performBeanValidation>true</performBeanValidation>
            <useBeanValidation>true</useBeanValidation>
            <sourceFolder>src/java/main</sourceFolder>
            <configPackage>my.path</configPackage>
            <generateSupportingFiles>false</generateSupportingFiles>
            <dateLibrary>java8</dateLibrary> <!-- java8 is a valid option from https://openapi-generator.tech/docs/generators/java/-->
            <interfaceOnly>true</interfaceOnly>
            <skipOverwrite>false</skipOverwrite>
            <useTags>true</useTags>
            <hideGenerationTimestamp>true</hideGenerationTimestamp>
          </configOptions>
        </configuration>
      </plugin>

Is there anything in these settings that pulls gradle into the generation?

dsyer commented 1 year ago

Is there anything in these settings that pulls gradle into the generation?

Sort of. You are using the openapi-generator-maven-plugin and by default it generates a full project with Maven and Gradle build configurations. You should be able to ignore them though. Your mistake will be something unrelated and unshown in the snippet above. A simple reproducer project in github would probably clear things up. It looks like maybe you are copying everything that the plugin generates into another location and that's probably not what you needed.

boardtc commented 1 year ago

Thanks for the reply. The way you say "I am using the openapi-generator-maven-plugin" suggests there may be another one?

This pom snippet worked with 5.0.0 previously in our code for years. My only goal here is to have it working with Spring Boot 3, not change any functionality.

The solution with 5.0.0 did not generate Gradle (I have double-checked), so it looks like that was added in v6 to be done by default? That said 2 weeks ago @madorb was looking for a similar plugin for gradle even though this does one does gradle, so I am quiet confused.

How do others stop Gradle from being generated by default?

dsyer commented 1 year ago

How do others stop Gradle from being generated by default?

I suspect they don't bother mostly. It hasn't been an issue for me - I just ignore some of the generated files.

boardtc commented 1 year ago

Fair enough. I don't care about Gradle being generated if it was not causing me an issue.

boardtc commented 1 year ago

With v5.0.0 I had only 1 generated java file in /v1/resources, with this version there is a whole project copied in there as shown above. I can't see any change in my pom file that is doing this, does anyone know what has changed between 5.0.0 & 6.3.0 that causes this? Or does one now just have to populate a .openapi-generator-ignore file?

boardtc commented 1 year ago

As mentioned above I was using spring-mvc library with v5. I have found an announcement ticket which says: image As suggested I tried spring-boot, but it I get the error:

[ERROR] 
java.lang.RuntimeException: Unknown library: spring-boot
Available libraries:
  jersey1
  jersey2
  jersey3
  feign
  okhttp-gson
  retrofit2
  resttemplate
  webclient
  resteasy
  vertx
  google-api-client
  rest-assured
  native
  microprofile
  apache-httpclient

I've added issues trying resttemplate and webclient. Which library is recommended in place of spring-mvc?

dsyer commented 1 year ago

I would have said, probably you need to use the "spring" generator instead of the "java" generator, but that was in the pom snippet you already posted. If you don't want to post a complete sample it's going to be hard to piece it all together.

boardtc commented 1 year ago

Thanks for engaging!! I posted my complete snippet above when you asked...ok I think you are looking for a SSCCE...it's a reasonably sized application so not sure how I would do that...

In the above snippet, I changed my v5.0.0 code to match your demo so I now use spring instead of java in execution 1 and java instead of spring in execution 2 like your demo....

I swapped them around and when using spring with the library it then recognises spring-boot as the library!!! Progress.

So in the root of my output folder I include .openapi-generator-ignore with the contents. But I don't think this is relevant to the generation, please correct me if I am wrong.

# Ignore everything
*  
# But not these files...
!.openapi-generator-ignore
!my.yaml
!*.java

So, I am now back to the Gradle error. My <output>src/main/resources/v1</output> is where gradle-wrapper.jar is generated. It's been pointed out to me that this should not be in my resources.

The copy is done by maven-resources-plugin:3.3.0 to copy the generated files from resources to target, This is where the error occurs but there would not be an issue if the jar was not in resources first, the maven-resources-plugin is not used directly in the pom so what calls the goal org.apache.maven.plugins:maven-resources-plugin:3.3.0:resources?

So for me, it comes back to how do I stop the openapi-generator-maven-plugin generating gradle artefacts? The above .openapi-generator-ignore file is only used after generation is my understanding.

@dsyer has pointed out that no one worries about the Gradle being created so I am wondering if others do the opposite of what I am doing and generate straight to target and then only copy the java API back to resources?

dsyer commented 1 year ago

I am wondering if others do the opposite of what I am doing and generate straight to target and then only copy the java API back to resources?

You will see that pattern in the sample I posted. The default location for generated source files is in target. You can then pick the ones you need using the resource plugin (or any other mechanism that suits you).

An SSCCE is by definition not your full-scale "reasonably sized application". It is a sample that reproduces your problem. It can be a chore to create such a sample, but it makes everyone much happier in the long run. I suggest that this discussion is way off topic for the issue now, and you should find another forum (Stack Overflow maybe?) to continue.

boardtc commented 1 year ago

The Gradle wrapper is not generated by a maven plugin. Is your project a maven or gradle project? It seems like maven, and if so, you almost certainly want to update your .openapi-generator-ignore to cause it to not generate either the maven or gradle files.

@matorb I have learned that the ignore file is to prevent files from being overwritten by the generator rather than being generated in the first place. There appears to be no way to control what's generated,

I suggest that this discussion is way off topic for the issue now, and you should find another forum (Stack Overflow maybe?) to continue.

@dsyer ongoing issues with the plugin but I thank you for your patience and won't post here again

boardtc commented 1 year ago

I don't see mention of Support for JakartaEE 9 in the release notes of 6.3, which was released? I'm confused. What's the solution to get this working?

wing328 commented 1 year ago

the release note only highlights some changes but not all.

please refer to https://github.com/OpenAPITools/openapi-generator/pulls?q=is%3Apr+is%3Amerged+milestone%3A6.3.0 for a full list of changes.

i'm still revising the release note.

boardtc commented 1 year ago

@wing328 thanks for letting me know. With a maven clean install I get lots of compilation errors like: /target/src/java/main/org/openapitools/client/Pair.java:[16,18] package javax.annotation does not exist That said this ticket is for adding Support of JakartaEE 9 and it's not included in the release.

wing328 commented 1 year ago

can you share more details on how you generate the code? e.g. spec, generator name, options, etc

craig-day commented 1 year ago

I can confirm that with this config and 6.3.0, I'm getting jakarta annotations

openApiGenerate {
    generatorName = "java"
    inputSpec = "$buildDir/openapi.yaml"
    outputDir = projectDir.path
    packageName = "foo"
    apiPackage = "foo"
    modelPackage = "foo"
    ignoreFileOverride = "$projectDir/.openapi-generator-ignore"
    configOptions = [
            apiPackage: "foo",
            modelPackage: "foo",
            asyncNative: "true",
            documentationProvider: "none",
            library: "resteasy",
            microprofileRestClientVersion: "3.0",
            useJakartaEe: "true"
    ]
}
boardtc commented 1 year ago

can you share more details on how you generate the code? e.g. spec, generator name, options, etc

Thanks for reply. My pom settings are above

dsyer commented 1 year ago

Can I suggest we close this issue and invite people to raise separate requests about specific combinations that do not currently work? Or maybe we could document which combinations actually do work a bit better somewhere. E.g. a table in the form

Generator Library Flags Supported
spring spring-http-interface X
spring spring-boot(*) useSpringBoot3=true X
spring spring-cloud useSpringBoot3=true X
java resttemplate useJakartaEe=true X
java webclient useJakartaEe=true X
java resteasy useJakartaEe=true X
java jersey1 useJakartaEe=true ?
java jersey2 useJakartaEe=true ?
java jersey3 useJakartaEe=true ?
java feign useJakartaEe=true ?
java okhttp-gson useJakartaEe=true ?
java retrofit2 useJakartaEe=true ?
java vertx useJakartaEe=true ?
java google-api-client useJakartaEe=true ?
java rest-assured useJakartaEe=true ?
java native useJakartaEe=true X
java microprofile useJakartaEe=true ?
java apache-httpclient useJakartaEe=true ?
jaxrs-spec ?
jaxrs-cxf-cdi ?
jaxrs-cxf-client ?
jaxrs-cxf-extended ?
jaxrs-cxf ?
jaxrs-jersey ?
jaxrs-resteasy-eap ?
jaxrs-resteasy ?

(*)Default for this generator. Generates a server.

bmarwell commented 1 year ago

Can I suggest we close this issue and invite people to raise separate requests about specific combinations that do not currently work? Or maybe we could document which combinations actually do work a bit better somewhere. E.g. a table in the form

Like this one from 2020? 😢 Already mentioned it a few times. Which entry in this table would that be? It is not bound to any library!

https://github.com/OpenAPITools/openapi-generator/issues/6881

dsyer commented 1 year ago

Library is an optional configuration setting. I'd be happy to add other generators if you tell me you have tested it and it works.

bmarwell commented 1 year ago

That would be jaxrs-spec in your table. it should be good for reasteasy, jersey and cxf as well as they all implement jaxrs. Btw, jaxrs is now called "restfulWs" starting with 3.0 (jakarta namespace). So, implement one, get three :) Example is in the issue I mentioned earlier.

My apps will always only use the API (dependency scope=provided in maven) and the implementation only in the runtime. So yes, it is already heavily used. Some IBMers working on Open Liberty did comment in the issue I mentioned, too.

dsyer commented 1 year ago

I didn't see any actual solutions proposed in that other issue, but I'm happy to take your word for it if you say it works. I just don't know what, precisely, you are saying works already. I don't see any references to a generator called "restfulWs", and there is a "useJakartaEe" flag for "jaxrs-spec" but does it work, and is it needed? Has anyone actually tested the other "jaxrs-*" generators?

boardtc commented 1 year ago

I have been looking at this again and using 6.4.0, trying to get unblocked. I have made some progress. @dsyer's example client does not UseSpringBoot3 and my config was not using useJakartaEe in the java generator, I had it in the 2nd spring generator.

When it recompiles I now get errors:

.../target/src/java/main/org/openapitools/client/GzipRequestInterceptor.java:[17,12] package okio does not exist
../.target/src/java/main/org/openapitools/client/GzipRequestInterceptor.java:[29,41] cannot find symbol
  symbol: class Interceptor
...
package okhttp3 does not exist
package com.google.gson does not exist
package com.google.gson.internal.bind.util does not exist
...

Some of these dependencies are in a new file /target/pom.xml, separate from target/generated-sources/pom.xml., but not all of them, e,g. okio is not.

I have my code working with v5.0.0 of the plugin for v2.7.5 of Spring Boot and there was no target/pom.xml generated.

This error is reported at #14270 with an example project

Others here have all working for useSpringBoot3 I believe. @madorb @arham-saeed @varminas did ye get unblocked?

dsyer commented 1 year ago

It would really be better to post this as a question on stackoverflow and/or provide a full working sample. Which of the matrix combinations in my table above are you using?

boardtc commented 1 year ago

I'm upgrading to spring boot v3 so the combination is 2 rows in your matrix: Java & useSpringBoot3 & useJakartaEe & WebClient (since restTemplate is deprecated in Spring 5). Full config.

I'm unsure why here is not suitable since people are trying to get workarounds for functionality which has not been implemented yet in the plugin.

dsyer commented 1 year ago

The way I read it, the config in that link has two executions with [generatorName,library,options] equal to [java,,useSpringBoot3=true] and [spring,spring-boot,useJakartaEe=true]. Neither of those combinations is in the table I drafted. I'm not sure they are valid, so maybe I can't read straight. A sample project would be so much easier, and we could move the long, distracting conversation over to there.

boardtc commented 1 year ago

Thanks for sticking with me. I know if you didn't; no one would as this is just one of 2000+ bugs multiple pages down the list that no one ever visits unless they encounter this problem. I will try and see if I can create a sscce, you will be the only one looking at it I think. The sscce for the 14270 bug, which I am now getting was never commented on by anyone.

Apologies, the config is updated now. I had moved useJakartaEe to the first execution. But are you saying, Java, useSpringBoot3, useJakartaEe is not valid? But Spring Boot 3 uses Jakarta, that's the nub of the whole thing,

       <execution>
            <id>openapi-server</id>
            <phase>generate-sources</phase>
            <goals>
              <goal>generate</goal>
            </goals>
            <configuration>
              <inputSpec>${project.basedir}/src/main/resources/v1/foo.yaml</inputSpec>
              <generatorName>java</generatorName>
              <output>src/main/resources/v1</output>
              <configOptions>
                <useSpringBoot3>true</useSpringBoot3>
                <useJakartaEe>true</useJakartaEe>
                <interfaceOnly>true</interfaceOnly>
              </configOptions>
            </configuration>
          </execution>
          <execution>
            <id>openapi-client</id>
            <phase>generate-sources</phase>
            <goals>
              <goal>generate</goal>
            </goals>
            <configuration>
              <generatorName>spring</generatorName>
              <modelNamePrefix>foo</modelNamePrefix>
              <configOptions>
                <library>spring-boot</library>
              </configOptions>
              <apiPackage>foo</apiPackage>
              <modelPackage>foo.model</modelPackage>
              <groupId>${project.groupId}</groupId>
              <artifactId>${project.artifactId}</artifactId>
              <artifactVersion>${project.version}</artifactVersion>
              <environmentVariables>
                <enablePostProcessFile>true</enablePostProcessFile>
              </environmentVariables>
            </configuration>
          </execution>
dsyer commented 1 year ago

Here's what I see in that fragment:

id generatorName library options
openapi-server java useSpringBoot3=true, useJakartaEe=true
openapi-client spring spring-boot

So the "server" execution generates a client, and it doesn't use a library so there won't be any Spring. And the "client" generates a server, and there is no useSpringBoot3 so it won't use the Jakarta namespace. At least one of us is still confused.