#25 Cross build the project for springdoc-openapi v2.x #27
Conversation
…e" them to have examples for both versions
…d-for-springdoc-openapi-2
JaCoCo code coverage report - springdoc-openapi-scala-1
|
JaCoCo code coverage report - springdoc-openapi-scala-2
|
| lazy val root = (project in file(".")) | ||
| .settings( | ||
| libraryDependencies ++= Seq( | ||
| "za.co.absa" %% "springdoc-openapi-scala-1" % "0.2.0-SNAPSHOT", |
There was a problem hiding this comment.
I think the version should be parameterized, otherwise you'll have to change it manually for every release. Also, it seems like the main build.sbt doesn't contain a version number?
There was a problem hiding this comment.
In main build.sbt the sbt-ci-release takes care of the version.
I'll think how to parametrise the lib version in example projects.
There was a problem hiding this comment.
I haven't managed to parametrize it the way I wanted (to have dynamic version passed by default), but I changed the code in #a5733e9221d1e70a3e25abc164c1fcc3a22c5b83 to be "good enough" in my opinion (version is not directly hardcoded).
I tried to use sbt-dynver and its dynver task (it is used in sbt-ci-release), but I always ended up with an error that "Setting cannot depend on task".
|
In general, it would be nice to provide build and run commands for the example projects as well, but this can be a separate PR |
There was a problem hiding this comment.
Pretty cool, I was just thinking if the artifact name communicates well that the number is the parametrized version of OpenAPI - so e.g. if instead springdoc-openapi-scala-1_2.13, if not use one of:
springdoc-openapi-scala_1_2.13
springdoc-openapi-scala-openapi-1_2.13
(just thinking, but I am not sure if the sbt-projectmatrix plugin allows such level of customization)
...e/src/main/scala/za/co/absa/springdocopenapiscala/examples/simple/OpenAPIConfiguration.scala
Outdated
Show resolved
Hide resolved
I think it would be possible, though it would probably have to be something like I decided to not use What about |
…springdoc-openapi versions used
I understand, that some of the longer options would make things more clear for the price of repetitiveness. It seems that you directly configure the way the name is created in https://github.com/AbsaOSS/springdoc-openapi-scala/pull/27/files#diff-a68c8c1a39b5aef73e0465ec46ceee9a832e943120828a681e13d11d988257dbR25-R26 However, I am not strongly opposing the current outcome, it would do. I am just trying to look for possible improvements. |
sbt-projectmatrixto cross-build the librarysbt-projectmatrix, now library code is in/libraryfolderspringdoc-openapi-scala-1_2.12,springdoc-openapi-scala-1_2.13springdoc-openapi-scala-2_2.12,springdoc-openapi-scala-2_2.13springdoc-openapi-scala-2build nowspringdoc-openapi-scala-1andspringdoc-openapi-scala-2build.sbtetc.springdoc-openapi-scala-1and one forspringdoc-openapi-scala-2, they are nearly the same but have different dependencies and example forspringdoc-openapi-scala-2has more things (enum, empty endpoint)Closes #25