-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API client namespace conflicts across Equinix's SDK #4
Comments
Agreed. The packages only differ by these lines:
A common APIClient would open cleaner possibilities for a unified Equinix API(s) Java package. We may be able to do that with Fabric and other services (everything else) that use OAuth Bearer tokens. Metal is the stand-out here. Perhaps we should put the Metal API client behind the added namespace instead of Fabric. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
APIs, Models and supporting files are created in following namespace for :
Metal :
ref : https://github.com/equinix-labs/metal-java/blob/main/spec/oas3.config.json
Fabric :
ref : https://github.com/equinix-labs/fabric-java/blob/main/spec/oas3.fabric.config.json
Initial vision was to have different openapi generated java sdk such as metal-java, fabric-java etc and eventually merge them into one equinix-java SDK. Which would share API client and other supporting files hence ideally Supporting files such as api client for fabric should be generated in com.equinix.openapi.
But in our case API client generated for fabric differs from metal due to shift in supported authorization model. Hence we need to maintain two different API clients. These leads to the realisation that even though they are in different project if API clients and supporting files are generated under com.equinix.openapi namespace then there will be a conflict during importing API client when both SDKs are consumed together.
The text was updated successfully, but these errors were encountered: