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
21.82k stars 6.58k forks source link

openapi 3.1.0 [ERROR] Error resolving ./paths/daas/res.yaml java.net.URISyntaxException: Illegal character in opaque part at index 2 #14648

Open kavish-chathuranga opened 1 year ago

kavish-chathuranga commented 1 year ago

Bug Report Checklist

Description
openapi-generator version

6.3.0

OpenAPI declaration file content or url

openapi: 3.1.0
info:
  title: test
  description: test
  # TODO: termsOfService field should be added later
  contact:
    name: test Support
    email: test
  version: 0.0.1
  license: 
    name: Copyright 
    identifier: EPL-2.0

servers:
- url: http://localhost:8080/api
  description: Localhost for development purposes

# TODO: Add the security requirments object later
security: []
tags:
  - name: DaaS RES Production Service
    description: Research workflow Production stage related DaaS Production Service APIs

paths:
  # Production Service
  /{tenantId}/counts:
    $ref: 'paths/daas/res.yaml'
Generation Details
Steps to reproduce
Related issues/PRs
Suggest a fix
rahulva commented 1 year ago

I face exact same issue with version 3.1.0

[INFO] --- openapi-generator-maven-plugin:6.3.0:generate (gen-java-server) @ proj--- [ERROR] Error resolving #/components/responses/ProjResponse java.net.URISyntaxException: Illegal character in opaque part at index 2: E:\A\B\proj\mod/src/main/resources/api/api.yaml

Maven config ` ...

${project.basedir}/src/main/resources/api/api.yaml

... `

mn3noa commented 1 year ago

Just check which openApi version is supported by openapi-generator-maven-plugin. In my case i use openapi-generator-maven-plugin 6.6.0. I got this error when i use openapi: 3.1.0 in my openApi yml file. With openapi: 3.0.3 it works.

dickerpulli commented 10 months ago

Windows path problem. Works on unix systems.

Gelunox commented 9 months ago

It seems like io.swagger.parser.v3:swagger-parser-v3 assumes the inputSpec it receives is a valid URI, which it is not on windows because windows uses backslashes.

CodegenConfigurator.java (line 670 on git tag v7.2.0, fe638d00)

SwaggerParseResult result = new OpenAPIParser().readLocation(inputSpec, authorizationValues, options);

with inputSpec resolving to C:\path\to\openapi\yaml/spec/file.yaml. This also happens in other locations, but I'm not sure where exactly, I didn't do in-depth testing.

If I change the inputSpec in my maven configuration to the absolute path with forward-slashes C:/path/to/openapi/yaml/spec/file.yaml instead of the ${project.parent.basedir}/spec/file.yaml I had before (and would like to continue using), the issue disappears.

I'm stuck on bypassing using <skipValidateSpec>true</skipValidateSpec> until this is resolved. Somehow this issue doesn't happen for the actual generation, only validation.

zoza commented 3 months ago

Maybe, it may help somebody. I worked around it by creating a new dynamic property "good.basedir" that contains the value of ${project.basedir} but replaced with slashes. (C:/someFolder/src/main/resources/api.yaml instead of C:\someFolder\src/main/resources/api.yaml)

The only downside is that it will be marked as a 'red' unresolved property in pom, but this can be suppressed by

<!--suppress UnresolvedMavenProperty -->

Define the plugin somewhere in the pom: (it may be parent pom too)

 <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>build-helper-maven-plugin</artifactId>
                    <version>3.6.0</version> 
                    <executions>
                        <execution>
                            <id>regex-path-property</id>
                            <goals>
                                <goal>regex-property</goal>
                            </goals>
                            <phase>validate</phase>
                            <configuration>
                                <name>good.basedir</name>
                                <value>${project.basedir}</value>
                                <regex>\\</regex>
                                <replacement>/</replacement>
                            </configuration>
                        </execution>                        
                    </executions>
                </plugin>

and then, just use:

<inputSpec>${good.basedir}/src/main/resources/api/api.yaml</inputSpec>

in the openapi-generator-maven-plugin

lindenquan commented 2 months ago

can you support relative path e.g. ./src/main/resources/api/api.yaml

eekboom commented 2 months ago

Currently evaluating openapi-generator against swagger-codegen and openapi-processor for a large-ish spec of a public sector project. On the very first try of the generator I am greeted with thousands of lines of error messages like this:

Error resolving schema #/components/schemas/ErrorMessage
java.net.URISyntaxException: Illegal character in opaque part at index 2: C:\dev\bitbucket\acme\openapi.yaml

I think this is the part the yaml it fails on (but it is hard to be sure, because "index 2" is completely meaningless):

          schema:
            $ref: '#/components/schemas/ErrorMessage'

The yaml passes validation, the ref looks valid and can be resolved by both IntelliJ IDEA and openapi-processor.

To actually get some generated code I have to set skipValidateSpec to true, but I still get all the error messages.

Not sure if this is the same issue or warrants a new one, but I do not have much hope, because this issue is one and a half years old and has not been fixed :-(

vlakar commented 1 month ago

Maybe, it may help somebody. I worked around it by creating a new dynamic property "good.basedir" that contains the value of ${project.basedir} but replaced with slashes. (C:/someFolder/src/main/resources/api.yaml instead of C:\someFolder\src/main/resources/api.yaml)

There is a dedicated maven variable for it: use ${project.baseUri}, not ${project.basedir}