[BUG] Path problem of inout spec file in windows: Illegal character in opaque part at index 2: C:....\ApiFirstServer-main\build\openapiDir\petstore.yaml

[SashaVolushkova]

Bug Report Checklist

• [X] Have you provided a full/minimal spec to reproduce the issue?
• [X] Have you validated the input using an OpenAPI validator (example)?
• [X] Have you tested with the latest master to confirm the issue still exists?
• [X] Have you searched for related issues/PRs?
• [X] What's the actual output vs expected output?
• [ ] [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

Problem with path declaring of file with specification. Have an error: Illegal character in opaque part at index 2: C:....\ApiFirstServer-main\build\openapiDir\petstore.yaml

openapi-generator version

6.5.0

OpenAPI declaration file content or url

the issue doest link to file formatting

Generation Details

the issue doest link to file formatting

Steps to reproduce

• OS: windows
• gradle version: 7.5
• openapi-generator-plugin-version: "6.5.0"
• add plugin: id "org.openapi.generator" version "6.5.0"
• set inputspec in validation:

openApiValidate {
	inputSpec = "${buildDir}/openapiDir/petstore.yaml".toString()
}

or

openApiValidate {
	inputSpec = "${buildDir}\\openapiDir\\petstore.yaml".toString()
}

• get an error: Illegal character in opaque part at index 2: C:...\ApiFirstServer-main\build\openapiDir\petstore.yaml
• the same problem is in openApiGenerate phase

Related issues/PRs

Related issue: https://github.com/OpenAPITools/openapi-generator/issues/14075

Suggest a fix

just format link before loading the file.

[martin-mfg]

Hi, I can't reproduce the problem. Like you, I'm using Windows 10, gradle 7.5 and "org.openapi.generator" version "6.5.0". I tried both inputSpec = "${buildDir}/openapiDir/petstore.yaml".toString() and inputSpec = "${buildDir}\\openapiDir\\petstore.yaml".toString().

I think the problem might be related to the way how you invoke gradle. How do you do that? I tried running ./gradlew openApiValidate from powershell 7, from cmd, from git bash and from WSL. It didn't fail anywhere. Are you invoking it from a script, from an IDE or something like that?

[NikitaCartes]

I am experiencing the same error as the author of this issue.

The error occurs for me in PowerShell, CMD, Git Bash, and IDEA. Additionally, when I include println "projectDir: " + projectDir in the build.gradle file, it returns projectDir: C:\git\myProject in all of the aforementioned environments.

[mn3noa]

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.

[kromit]

This also occurs with maven on Windows 11 with openapi-generator-maven-plugin: 7.0.0 an openapi: 3.1.0 in the file.

  [ERROR] Error resolving schema ./model/v1/SomeObj.yaml
  java.net.URISyntaxException: Illegal character in opaque part at index 2: C:\project\folder/../src/main/resources/openapi.yaml

Changing back to openapi: 3.0.3 within this same file works again.

[wing328]

please try openapi-generator v7.0.1 which provides beta support for v3.1.0 spec.

[kromit]

Same error with 7.0.1., but it seems like its is a problem of swagger resolve

[ERROR] Error resolving schema ./model/v1/SomeObj.yaml
java.net.URISyntaxException: Illegal character in opaque part at index 2: C:\project\folder/../src/main/resources/openapi.yaml
at java.net.URI$Parser.fail (URI.java:2976)
at java.net.URI$Parser.checkChars (URI.java:3147)
at java.net.URI$Parser.parse (URI.java:3183)
at java.net.URI.<init> (URI.java:623)
at io.swagger.v3.parser.reference.ReferenceUtils.resolve (ReferenceUtils.java:29)
at io.swagger.v3.parser.reference.ReferenceVisitor.resolveSchemaRef (ReferenceVisitor.java:227)
at io.swagger.v3.parser.reference.ReferenceVisitor.visitSchema (ReferenceVisitor.java:141)
at io.swagger.v3.parser.reference.OpenAPI31Traverser.traverseSchema (OpenAPI31Traverser.java:790)
at io.swagger.v3.parser.reference.OpenAPI31Traverser.traverseSchemaMap (OpenAPI31Traverser.java:946)
at io.swagger.v3.parser.reference.OpenAPI31Traverser.traverseComponents (OpenAPI31Traverser.java:169)
at io.swagger.v3.parser.reference.OpenAPI31Traverser.traverseOpenApi (OpenAPI31Traverser.java:128)
at io.swagger.v3.parser.reference.OpenAPI31Traverser.traverse (OpenAPI31Traverser.java:65)
at io.swagger.v3.parser.reference.OpenAPIDereferencer31.dereference (OpenAPIDereferencer31.java:74)
at io.swagger.v3.parser.OpenAPIV3Parser.resolve (OpenAPIV3Parser.java:225)
at io.swagger.v3.parser.OpenAPIV3Parser.readContents (OpenAPIV3Parser.java:181)
at io.swagger.v3.parser.OpenAPIV3Parser.readLocation (OpenAPIV3Parser.java:97)
at io.swagger.parser.OpenAPIParser.readLocation (OpenAPIParser.java:16)
at org.openapitools.codegen.config.CodegenConfigurator.toContext (CodegenConfigurator.java:637)
at org.openapitools.codegen.config.CodegenConfigurator.toClientOptInput (CodegenConfigurator.java:695)
at org.openapitools.codegen.plugin.CodeGenMojo.execute (CodeGenMojo.java:884)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
at org.apache.maven.wrapper.BootstrapMainStarter.start (BootstrapMainStarter.java:52)
at org.apache.maven.wrapper.WrapperExecutor.execute (WrapperExecutor.java:161)
at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:73)

[black-snow]

Same here, generator 7.0.1, Win11, Gradle 8.3, OpenAPI 3.1.0 - will fall back to 3.0.3 for now.

[craigmit]

Same exception as @kromit . openapi-generator-maven-plugin 7.0.1. Win11. Maven 3.6.3. Java 17.0.6. OpenAPI 3.1.0 - falling back to 3.0.3.

[wing328]

Same error with 7.0.1., but it seems like its is a problem of swagger resolve

right, please report the issue to swagger parser. thanks.

[shorn]

swagger-parse has this open issue: https://github.com/swagger-api/swagger-parser/issues/1511

That issue references https://github.com/OpenAPITools/openapi-generator/issues/10053 on this project (which this issue is maybe a duplicate of?)

There is a possible workaround mentioned (involving use of a later version of swagger-parser-v3) with the openapi-generator Gradle plugin.

My functioning workaround is to just fall back to using openapi spec 3.0.3.

[shorn]

Another possible workaround is to use the cli via docker, to take advantage of docker-desktop running the container in a Linux environment.

Note that docker-desktop for Windows requires a paid subscription for commercial use.

Here's my Gradle task that seems to be working:

tasks.register('dockerRunApiIdl', Exec) {
  group="docker"
  dependsOn dockerStageApiIdl

  ignoreExitValue = true

  doFirst {
    delete file(outputDir)
  }

  commandLine osCmd('docker', 'run', '--rm',
    '--volume', "${file(stagingDir).path}:/input",
    '--volume', "${file(outputDir).path}:/output",
    'openapitools/openapi-generator-cli',
    'generate',
    '--input-spec', '/input/kopi-openapi-3.1.yaml',
    '--config', '/input/spring-generator-config.json',
    '--output', '/output',
  )
}

[otrebor]

I had the same problem with Maven. The "" symbol , used in the inputspec configuration parameter, creates the problem during the parsing of the URI containing the path to the yaml file.

my workaround is to create a property in my pom:

<input.spec.original>${basedir}/src/main/resources/api/openapi.yaml<input.spec.original>

then I replace all the "" symbols to "/" using a maven plugin.

org.codehaus.mojo build-helper-maven-plugin ${maven.build-helper.version} regex-property regex-property project.apis.folder ${project.apis.folder.original} \\ / false

And finally i pass the value of the property named "project.apis.folder" as input for the OpenApi generator.

org.openapitools openapi-generator-maven-plugin 7.1.0 ... ${project.apis.folder} ... ...

I hope this workaround can help.

[rongli-mx]

I have the same problem on Windows with Maven 3.8.7, OpenAPI Generator 7.2.0 and OpenAPI Version 3.1.0. The solution from @otrebor works for me. The maven plugin passes the <inputSpec> directly to the Swagger OpenAPIParser:

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

OpenAPIParser expect inputSpec as URL, so I think the maven plugin should convert <inputSpec> to a valid URL.

[marcoblos]

As a possible workaround, you can use a relative path, for instance: <inputSpec>src/main/resources/open-api-spec.yaml</inputSpec>

[Gelunox]

As a possible workaround, you can use a relative path, for instance: <inputSpec>src/main/resources/open-api-spec.yaml</inputSpec>

Note that this doesn't work with multi module projects, especially if the spec is in a different module.

[marcoblos]

As a possible workaround, you can use a relative path, for instance: <inputSpec>src/main/resources/open-api-spec.yaml</inputSpec>

Note that this doesn't work with multi module projects, especially if the spec is in a different module.

That's true!

[jbroekhuizen-maqqie]

I was also facing the issue today. The "${buildDir}" part is returning a path including backslashes (''), which was for me causing the problem. Replacing them to a forward slash ('/') was the solution for me. This link was the solution for me: https://www.bennorthrop.com/Snippets/string-replace-in-maven-with-regex.php

[mtrakal]

it's broken with: openapi: 3.1.0 when change to: openapi: 3.0.x it generate.

openapi-generator = { id = "org.openapi.generator", version = "7.7.0" }

Windows 11 + openapi: 3.1.0

problem is path which it try to use: D:\ instead of /

 -Illegal character in opaque part at index 2: D:\Projects\project\module\api/api.yaml

        at org.openapitools.codegen.config.CodegenConfigurator.toContext(CodegenConfigurator.java:717)
        at org.openapitools.codegen.config.CodegenConfigurator.toClientOptInput(CodegenConfigurator.java:744)
        at org.openapitools.generator.gradle.plugin.tasks.GenerateTask.doWork(GenerateTask.kt:937)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:125)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:51)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:29)

---

Edit: added my workaround from https://github.com/OpenAPITools/openapi-generator/issues/14075#issuecomment-2266095826

Simple workaround:

openApiGenerate {
    // add .replace("\\","/") behind yaml file path :)
    inputSpec = "$projectDir/specification.yaml".replace("\\","/")

[BierDav]

this workaround fixes the issue for me: https://github.com/OpenAPITools/openapi-generator/issues/14075#issuecomment-2266095826

[koscejev]

Encountered the same issue. Here's a workaround that uses a newer Gradle approach (.kts version):

inputSpec = layout.buildDirectory.file("resources/main/openapi.yaml").map { it.asFile.toURI().toString() }

Note: this is using the processed resource (after filtering, etc.) from buildDirectory, so:

tasks.getByName("openApiValidate") { dependsOn(tasks.processResources) }

[tvogel8570]

@otrebor I would like to use 3.1.0 but blocked by the tooling problem. Any chance you could post a more complete pom.xml with your workaround for this issue?

[snv]

I had the same problem with Maven. The "\" symbol , used in the inputspec configuration parameter, creates the problem during the parsing of the URI containing the path to the yaml file.

my workaround is to create a property in my pom:

<input.spec.original>${basedir}/src/main/resources/api/openapi.yaml<input.spec.original>

then I replace all the "\" symbols to "/" using a maven plugin.

org.codehaus.mojo build-helper-maven-plugin ${maven.build-helper.version} regex-property regex-property project.apis.folder ${project.apis.folder.original} \\ / false And finally i pass the value of the property named "project.apis.folder" as input for the OpenApi generator.

org.openapitools openapi-generator-maven-plugin 7.1.0 ... ${project.apis.folder} ... ... I hope this workaround can help.

Still happening :(

For those having to use maven, an example of applying otrebor's helpful workaround would be:

<inputSpec.original>${project.build.directory}/dependency/openapi.yaml</inputSpec.original>

in properties

then

<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>build-helper-maven-plugin</artifactId>
	<version>3.6.0</version>
	<executions>
		<execution>
			<id>fix-path-for-swagger</id>
			<goals>
				<goal>regex-property</goal>
			</goals>
			<configuration>
				<failIfNoMatch>false</failIfNoMatch>
				<name>inputSpec-fixed</name>
				<value>${inputSpec.original}</value>
				<regex>\\</regex>
				<replacement>/</replacement>
			</configuration>
		</execution>
	</executions>
</plugin>

in build-plugins

and

<!--suppress UnresolvedMavenProperty  - wird vom build-helper-mave-plugin gesetzt-->
<inputSpec>${inputSpec-fixed}</inputSpec>

in the configuration part of the openapi-generator-maven-plugin

I use this in a multi-module project, where i pull in the specification file as a dependency from the other module.

[mk239]

Using project.baseUri instead of project.basedir works for maven setups. The open api maven plugin is fine with the uri format.

[mk239]

Issue is adressed to swagger-api team, see https://github.com/swagger-api/swagger-parser/issues/2136