Revert "remove everything" #1
Conversation
This reverts commit 64864bd.
| openApiIgnoreFileOverride := s"$root/openapi-ignore-file", | ||
| libraryDependencies ++= Seq( | ||
| "com.softwaremill.sttp.client" %% "core" % "2.2.0", | ||
| "com.softwaremill.sttp.client" %% "json4s" % "2.2.0", |
There was a problem hiding this comment.
the version should be extracted to a constant. Also, I'd use circe as it's the more popular choice
There was a problem hiding this comment.
We cannot use circe, as this plugin contains openapi-generator in 4.3.1 version which doesn't contain improved sttp generator. I've created an issue to release newer version: OpenAPITools/sbt-openapi-generator#15
There was a problem hiding this comment.
even better, the version of the openapi-generator to use could be configured as a setting of the plugin (not hard-coded)?
There was a problem hiding this comment.
I also thought about such approach but that seems to counter the openapi convention. Other plugins like gradle and maven are released each time a new version of generator came out. Probably there is a good reason for that. There is already an issue in sbt-openapi-plugin project to setup an automatic release process based on openapi-generator's releases. (OpenAPITools/sbt-openapi-generator#2)
| "org.json4s" %% "json4s-jackson" % "3.6.8" | ||
| ), | ||
| (compile in Compile) := ((compile in Compile) dependsOn openApiGenerate).value, | ||
| cleanFiles += baseDirectory.value / "src" |
There was a problem hiding this comment.
I think we should generate those into src-managed. See: https://www.scala-sbt.org/1.x/docs/Howto-Generating-Files.html
Maybe we can also leverage the sourceGenerators task?
There was a problem hiding this comment.
That looks awesome, unfortunately we can't use sourceGenerators because this requires all files to be compile-able and despite explicitly saying to generator that we want only src/main files it also generates .openapi-generator-ignore and .openapi-generator/VERSION files ...
I also agree that we should use sourceManaged, but while it works I am not sure if it is safe since the generator still doesn't allow us change the destination of the source files - we can only change the baseDir directory.
So it looks like this:
$ tree petstore-api/target/scala-2.12
petstore-api/target/scala-2.12
├── src_managed
│ └── main
│ └── demo
│ └── src
│ └── main
│ └── scala
│ └── org
│ └── openapitools
│ └── client
│ ├── api
│ │ ├── EnumsSerializers.scala
│ │ ├── PetApi.scala
│ │ ├── StoreApi.scala
│ │ └── UserApi.scala
│ ├── core
│ │ ├── ApiInvoker.scala
│ │ ├── requests.scala
│ │ └── Serializers.scala
│ └── model
│ ├── ApiResponse.scala
│ ├── Category.scala
│ ├── Order.scala
│ ├── Pet.scala
│ ├── Tag.scala
│ └── User.scalaSo after all it seems like this ignoreFile isn't what we were looking for.
There was a problem hiding this comment.
I wonder what implications would be of doing it in the openapi-way. We could generate a self-containing sbt-project into petstore-api directory and since it contains build.sbt file it will be recognized by the root project. am I right?
There was a problem hiding this comment.
I wonder what implications would be of doing it in the openapi-way. We could generate a self-containing sbt-project into petstore-api directory and since it contains build.sbt file it will be recognized by the root project. am I right?
yes, but it would also contain its own settings, which would overwrite user's settings. We don't want to do that - the plugin should only do its job: generate a client, and minimally interfere with other parts of the project
There was a problem hiding this comment.
That looks awesome, unfortunately we can't use
sourceGeneratorsbecause this requires all files to be compile-able and despite explicitly saying to generator that we want onlysrc/mainfiles it also generates.openapi-generator-ignoreand.openapi-generator/VERSIONfiles ...I also agree that we should use
sourceManaged, but while it works I am not sure if it is safe since the generator still doesn't allow us change the destination of the source files - we can only change the baseDir directory.
Ah, so that's a bug in the openapi sbt-plugin or the generator. We'll have to live with that so far :). So maybe we can leave this as-is, but add a comment on why sourceGenerators are not used, and link to issues (if they exist) which report the problem?
So after all it seems like this ignoreFile isn't what we were looking for.
Well it is, but needs fixing, no? ;)
There was a problem hiding this comment.
Ah, so that's a bug in the openapi sbt-plugin or the generator. We'll have to live with that so far :). So maybe we can leave this as-is, but add a comment on why sourceGenerators are not used, and link to issues (if they exist) which report the problem?
Agree, currently there is no issue apart from OpenAPITools/openapi-generator#6685 but I think that it will evolve into new one, probably in sbt-openapi-plugin.
Well it is, but needs fixing, no? ;)
I think that it is something which by coincidence was partially useful for us, but I cannot image it being changed in such a way that will allow us to put sources into srcManaged directly. I wasn't just build for that purpose.
There was a problem hiding this comment.
I just filed a PR against OpenAPITools that would allow use of sbt source generators by disabling metadata file generation in a way compatible with the sbt plugin.
If that's interesting to you still it could use some support!
| implicit val serializer: SttpSerializer = new SttpSerializer() | ||
| implicit val apiKeyValue = ApiKeyValue("") | ||
| implicit val backend = HttpURLConnectionBackend() | ||
| println(StoreApi().getInventory().send()) |
There was a problem hiding this comment.
ah the server address is in the yaml ... but there is a way to overwrite it here, if we wanted to call another address?
There was a problem hiding this comment.
Yes, this is the default parameter which is defined for the apply method from the companion object
This reverts commit 64864bd.