jra
Minnow
Posts: 1
|
Post by jra on Mar 24, 2021 0:58:54 GMT
Hi.... I'm having similar issues with the OpenAPI-Tool generator repo1.maven.org/maven2/org/openapitools/openapi-generator-cli/5.1.0/openapi-generator-cli-5.1.0.jarjava -jar openapi-generator-cli-5.1.0.jar generate -g rust --library reqwest -i http://redfish.dmtf.org/schemas/v1/openapi.yaml -o redfish --additional-properties=packageName=redfishlib --verbose > redfish\Generated.out 2> redfish\generated.err
[main] INFO o.o.c.config.CodegenConfigurator -
VERBOSE MODE: ON. Additional debug options are injected
- [debugOpenAPI] prints the OpenAPI specification as interpreted by the codegen
- [debugModels] prints models passed to the template engine
- [debugOperations] prints operations passed to the template engine
- [debugSupportingFiles] prints additional data passed to the template engine
[main] WARN io.swagger.v3.parser.OpenAPIV3Parser - Exception while resolving:
java.lang.RuntimeException: Could not find definitions/context in contents of http://redfish.dmtf.org/schemas/v1/odata-v4.yaml
at io.swagger.v3.parser.ResolverCache.loadRef(ResolverCache.java:145) DSP8010_2018.2_Telemetry generates just fine... And, yes... I do need the Swordfish...) Edit: I did find that most $ref were not quoted... like: $ref: http://redfish.dmtf.org/schemas/v1/Message.v1_1_2.yaml#/components/schemas/Message_v1_1_2_Message They should be: $ref: 'http://redfish.dmtf.org/schemas/v1/Message.v1_1_2.yaml#/components/schemas/Message_v1_1_2_Message' Since everything after the "#" should be considered a comment in YAML... Also... Would it be possible to make the references relative ? All the links are absolute and go to the dmtf website... $ref: http://redfish.dmtf.org/schemas/v1/Message.v1_1_2.yaml#/components/schemas/Message_v1_1_2_Message
preferred: $ref: 'Message.v1_1_2.yaml#/components/schemas/Message_v1_1_2_Message' (Not sure if you can do something about that... ) Thanks JR
|
|
|
Post by mraineri on Mar 24, 2021 15:48:29 GMT
From what I understand about YAML, strings like that do not need explicit quotes; at least from the documentation I'm reading, YAML strings can be unquoted, single quoted, or double quoted. If it's better to have quotes for the sake of clarity, I can take a look at how we can specify the YAML file output with the pyyaml module. Part of the desire to make these references absolute is to allow for users to simply download the DSP8010 openapi.yaml file without having to download additional schema bundles. We have direct references to some Swordfish schemas, so we'd like to avoid requiring additional download steps. Unfortunately I have not had a chance to do more debugging as to why absolute references are failing like that, but changing things to be local references is something we can consider if we're continuing to struggle with absolute references. One other update though. I did find the root cause of those empty Resource objects. Long story short, it stemmed from how we construct our JSON Schema files from CSDL (which ultimately go into OpenAPI files). I have a fix pending here: github.com/DMTF/Redfish-Tools/pull/352
|
|
|
Post by thiagomarsal on May 24, 2021 22:36:29 GMT
I'm following the discussion and I'm also facing some difficulties to generate the Java client API using the Maven OpenApi plugin below: openapi-generator.tech/docs/plugins/#mavenThe error below remain unsolved for me while trying to generate the client for version "DSP8010_2021.1a": [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /C:/Users/tfarias/eclipse-workspace/redfish-openapi-java-client/target/generated-sources/openapi/src/main/java/org/openapitools/client/model/MessageMessage.java:[19,37] cannot find symbol symbol: class ERRORUNKNOWN location: package org.openapitools.client.model [ERROR] /C:/Users/tfarias/eclipse-workspace/redfish-openapi-java-client/target/generated-sources/openapi/src/main/java/org/openapitools/client/model/SoftwareInventoryMeasurementBlock.java:[19,37] cannot find symbol symbol: class ERRORUNKNOWN location: package org.openapitools.client.model [ERROR] /C:/Users/tfarias/eclipse-workspace/redfish-openapi-java-client/target/generated-sources/openapi/src/main/java/org/openapitools/client/model/ResourceResource.java:[18,37] cannot find symbol symbol: class ERRORUNKNOWN location: package org.openapitools.client.model [ERROR] /C:/Users/tfarias/eclipse-workspace/redfish-openapi-java-client/target/generated-sources/openapi/src/main/java/org/openapitools/client/model/ResourceLocation.java:[19,37] cannot find symbol symbol: class ERRORUNKNOWN location: package org.openapitools.client.model [INFO] 4 errors However, I have fixed the errors above manually and published them on the link below. Trying to save time, I would like to share it with someone who is in need. github.com/thiagomarsal/redfish-openapi-java-clientSincerely, Thiago Farias
|
|
|
Post by mraineri on Jun 17, 2021 14:58:07 GMT
Sorry, I've had other things piling up and haven't had a chance to dig into this further.
Specifically with Java, I have not tested building against that. It's possible the Java support is not as far along as other languages (Go seems to be the most mature). I can try Java when I start looking at this more.
|
|
|
Post by mickbjones on Oct 18, 2021 17:59:28 GMT
Sorry, I've had other things piling up and haven't had a chance to dig into this further. Specifically with Java, I have not tested building against that. It's possible the Java support is not as far along as other languages (Go seems to be the most mature). I can try Java when I start looking at this more. Hi Mike, I've found the problem to be the Swordfish references used with DriveCollection.yaml. At the time of posting, both the release (2021.2) and the Gitbub repo /openapi have this same problem.
Problem
1) In the 'openapi/' folder the 'openai.yaml' has links to the following schema ref: redfish.dmtf.org/schemas/swordfish/v1/DriveCollection.yaml#/components/schemas/DriveCollection_DriveCollection *Note: The local schema has the same schema 'DriveCollection.yaml' that does NOT have the odata reference problem. 2) Opening this file from the URL yields the following (partial extract): components: schemas: DriveCollection_DriveCollection: additionalProperties: false description: A Collection of Drive resource instances. properties: '@odata.context': $ref: redfish.dmtf.org/schemas/v1/odata-v4.yaml#/definitions/context 3) opening the ref link for redfish.dmtf.org/schemas/v1/odata-v4.yaml yields the following: components: schemas: odata-v4_context: description: The OData description of a payload. format: uri-reference readOnly: true type: string x-longDescription: The value of this property shall be the context URL that describes the resource according to OData-Protocol and shall be of the form defined in the Redfish specification. 4) Therefore, there is no '/definitions/context' schema in the referenced 'odata-v4' schema. This reference to DriveCollection.yaml in the 'Swordfish' schema occurs 11 times. Solution (I think) The newest Swordfish schema v1.2.2 does not include a 'DriveCollection' schema. So my best guess is that the Swordfish schema referenced is out of date and that "DriveCollection" was subsumed into Redfish. Maybe the 'DriveCollection' references should refer to the local file? In which case the problem would resolve itself because in both release 2021.2 and the Github repo the 'DriveCollection.yaml' has the correct odata-v4 references.
I can send screenshots, etc, but it should be immediately obvious by following the links from the root 'openapi.yaml' file. Just do a search for 'swordfish/v1/DriveCollection.yaml'.
|
|
|
Post by mraineri on Oct 18, 2021 18:36:24 GMT
I thought we made changes to the JSON to OpenAPI converter to address this. Looking here, apparently we did not: github.com/DMTF/Redfish-Tools/blob/master/json-to-openapi-converter/json-to-yaml.py#L271So, we need to reproduce the OpenAPI files with referenced if statement removed. All of this stems from the transfer of ownership of the DriveCollection schema. Since it came into the DMTF, SNIA has stopped maintaining it, therefore the link currently shown in openapi.yaml references an older copy with some older methods of supporting the OData definitions.
|
|
|
Post by mickbjones on Oct 18, 2021 18:49:00 GMT
A short term fix is to replace all instances of 'https://redfish.dmtf.org/schemas/swordfish/v1/DriveCollection.yaml' in 'openapi.yaml' with local ref 'DriveCollection.yaml' or 'https://redfish.dmtf.org/schemas/v1/DriveCollection.yaml'. This gets me the following output for release 2021.2 using openapi-generator-cli (v5.2.1):
Validating spec (openapi.yaml) [main] INFO o.o.codegen.utils.ModelUtils - [deprecated] inheritance without use of 'discriminator.propertyName' has been deprecated in the 5.x release. Composed schema name: null. Title: null [main] INFO o.o.codegen.utils.ModelUtils - [deprecated] inheritance without use of 'discriminator.propertyName' has been deprecated in the 5.x release. Composed schema name: null. Title: null [main] INFO o.o.codegen.utils.ModelUtils - [deprecated] inheritance without use of 'discriminator.propertyName' has been deprecated in the 5.x release. Composed schema name: null. Title: null [main] INFO o.o.codegen.utils.ModelUtils - [deprecated] inheritance without use of 'discriminator.propertyName' has been deprecated in the 5.x release. Composed schema name: null. Title: null [main] INFO o.o.codegen.utils.ModelUtils - [deprecated] inheritance without use of 'discriminator.propertyName' has been deprecated in the 5.x release. Composed schema name: null. Title: null [main] INFO o.o.codegen.utils.ModelUtils - [deprecated] inheritance without use of 'discriminator.propertyName' has been deprecated in the 5.x release. Composed schema name: null. Title: null No validation issues detected.
|
|
|
Post by mickbjones on Oct 19, 2021 1:42:39 GMT
|
|