-
Notifications
You must be signed in to change notification settings - Fork 1
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
Revert "remove everything" #1
Changes from all commits
4e28198
9ab35e9
52da34c
d956824
c879f91
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
# sttp-openapi example |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
name := "sttp-openapi-generator-example" | ||
|
||
version := "0.1" | ||
|
||
scalaVersion := "2.13.2" | ||
|
||
lazy val petstoreApi: Project = project | ||
.in(file("petstore-api")) | ||
.settings( | ||
openApiInputSpec := s"${baseDirectory.value.getPath}/petstore.yaml", | ||
openApiGeneratorName := "scala-sttp", | ||
//We can't use src_managed because there is no option to tell openapi-generator to generate files into different folder than src | ||
//see https://github.com/OpenAPITools/openapi-generator/issues/6685 for more details | ||
openApiOutputDir := baseDirectory.value.name, | ||
//Below setting is needed to configure generator not to generate other files besides src/main/scala | ||
openApiIgnoreFileOverride := s"${baseDirectory.in(ThisBuild).value.getPath}/openapi-ignore-file", | ||
libraryDependencies ++= Seq( | ||
"com.softwaremill.sttp.client" %% "core" % "2.2.0", | ||
"com.softwaremill.sttp.client" %% "json4s" % "2.2.0", | ||
"org.json4s" %% "json4s-jackson" % "3.6.8" | ||
), | ||
//We can't use sourceGenerators because this requires all files to compile and openapi-generator generates | ||
//some additional metadata files which breaks compilation. | ||
//see https://github.com/OpenAPITools/openapi-generator/issues/6685 for more details | ||
(compile in Compile) := ((compile in Compile) dependsOn openApiGenerate).value, | ||
//As we don't generate files into src_managed we have to do cleaning by our own | ||
cleanFiles += baseDirectory.value / "src" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That looks awesome, unfortunately we can't use I also agree that we should use $ 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.scala So after all it seems like this ignoreFile isn't what we were looking for. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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
Well it is, but needs fixing, no? ;) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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.
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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! |
||
) | ||
|
||
lazy val core = project | ||
.in(file("core")) | ||
.dependsOn(petstoreApi) | ||
|
||
lazy val rootProject = project | ||
.in(file(".")) | ||
.aggregate(petstoreApi, core) |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
package sttp.example | ||
|
||
import org.openapitools.client.api.StoreApi | ||
import org.openapitools.client.core.{ApiKeyValue, SttpSerializer} | ||
import sttp.client.HttpURLConnectionBackend | ||
|
||
object Main { | ||
def main(args: Array[String]): Unit = { | ||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, this is the default parameter which is defined for the |
||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
* | ||
**/* | ||
!**/src/main/scala/**/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)