I was playing around with openapi-generator, and cant find a way to get it to generate valid scala code for scala-play-server.
I use the petstore.json I downloaded from swagger.io, and run
openapi-generator generate -i petstore.json -g scala-play-server
It seems to kinda work, except, the models it generates look like this:
case class Tag(
id: Option[Long],
name: Option[String]
additionalProperties:
)
... which, of course, isn't valid scala code, and fails to compile.
I tried adding
--additional-properties=disallowAdditionalPropertiesIfNotPresent=false
to command line as some website I googled suggested, but that didn't make any difference (and neither did changing false to true).
I guess, I could just put together a sed script, to run on all generated files and replace additionalProperties: with additionalProperties: Map[String, Any] (or just remove those lines completely - no idea why I would want them there), but thought I'd just ask first in case someone knows about an easy fix that wouldn't be this "hacky" ...
Disclaimer, I am not a scala developer, but I spend a lot of time with the open-api-generator.
It appears this is a known bug that was reported in September 2022. However, it doesn't seem to have any comments or traction. Feel free to add comments to the existing ticket. Sometimes that helps them gain visibility.
I don't know if it matters, but I tested the other scala server generators, and all of them generate the class without the additional properties. So, if you are able to use a different scala server generator, that may be a work around.
Another potential work around, if you don't ever plan to use the additionalProperties feature of OAS, would be to remove it from the mustache template. You can do this via templating. Copy the caseClass.mustache and the model.mustache templates into a directory of your choosing, and delete the references to the additionalProperties. Then, add the template directory to your CLI generator via -t/--template.
I tried using the templating method myself and it works, however you will no longer be able to use the additionalProperties feature from OAS in your schema.
Related
I wanted writing an IDE plugin to simplify work with references to code in my documentation, but decided to first check the existence of a specification (like URI) so as not to reinvent the wheel.
I tried to find the answer to this on the internet but failed.
We know that such references work in different IDEs:
appRoot.folder.file.Class#method
appRoot.folder.file:35
appRoot/fodler/file.ext:35
But what if you need to get the path to the nested property JSON or XML?
I naively imagine that the sign # means the root and then for the JSON path I could use something like this:
appRoot/folder/jsonFile.json#oneLevelProp.twoLevelProp
But this of course does not work at the current moment in any IDE that I know of.
I have a factory that I use in several builders and I set builder specific settings via util.Property and util.Interpolate. While this works fine for repourl and branch it simply doesn't work for codebase. The following piece of code shows the source step how I would like to use it in my Buildbot configuration.
factory.addStep(
steps.Git(repourl=util.Interpolate('git://repo_base_path/%(prop:build_repository)s', default=''),
branch=util.Property('build_branch', default='master'),
mode='full',
codebase=util.Interpolate('%(prop:build_repository)s', default=''),
method='copy', submodules=True, clobberOnFailure=True)
)
)
Without the codebase part all worked fine. I then figured I would need to set the codebase for some cases so I added the codebase line, resulting in the following error:
[-] Configuration Errors:
[-] error while parsing config file: sequence item 1: expected
string, Interpolate found traceback in logfile
Does anybody know why it is not possible to set the codebase via Interpolate while it is no problem to do the same thing with repourl?
Does somebody have an idea how to set the codebase for the source step to something different from '' and still not create a separate factory instance for every builder?
Any insights into this and any helpful suggestion is highly appreciated.
I think this is a bug in Buildbot. Looking at the Buildbot 0.8.12 sources, I can see that in buildbot/steps/source/git.py, in class Git, the renderables attribute includes "codebase", which should mean that you can use Interpolate in this way. Presumably some other code is assuming it can interpret codebase as a string at the time the configuration is parsed.
In other words, as far as I can tell, you're doing something that the Git class claims to support.
It looks like the old-style Git support in buildbot/steps/source/oldsource.py doesn't support codebase being a renderable, but it doesn't look to me like you're using that. I'm not entire sure, though, because I'm not sure what steps.Git refers to.
Lets say for example I write many times priavte instead private.
Is there a way to let Eclipse automatically fix my common typo?
Something like construct a map of my common typo to its desire fix,
and then just let Eclipse fix it without asking me about that.
Are there any other IDE\editors that have such support?
There is no builtin support for automatically changing strings. The closest to your request are the templates of the Java editor, but even those must explicitly be activated using CtrlSpace.
To get around your problem, I suggest simply not to write that much yourself. If you want to declare a private field, type just "pr" and hit CtrlSpace to invoke code completion. Eclipse can do code completion quite well, often even without any trigger characters (try it with an empty class file).
In Eclipse 3.7 I've seen java code templates with several variations of the ${import} command:
${:import}
${imp:import}
${x:import}
What's the difference between them?
In the above example you have created 3 variables:
"" (ie blank)
"imp"
"x"
You can use these names to refer to the variables later on within the template. However this seems to be largely useless in the case of import statements.
To get an idea of how this might be used usefully take a look at arraymerge, which is a template shipped with Eclipse, and you will see the result variabe being used in a few places.
I suggest taking a look at the templates that ship with Eclipse and the excellent Useful Eclipse Java Code Templates question to learn a bit more.
Note: Within a template all variables must have unique names, so if you took your example above and added
${:importStatic}
You will get an error, as you have already used "" (blank) as a variable name.
...and why has the package this misleading name (I assumed it had something to do with JavaME or mobile/smart phones)?
I found no references on the internet about scala.mobile.Code or scala.mobile.Location at all nor did I manage to do anything with those classes except getting ClassCastExcetions or NoSuchMethodErrors.
Actually there is not even a single test against scala.mobile in the Scala's test tree which could help understanding that code.
The classes really smell like they were forgotten in the source tree a long time ago and got accidentally released since that.
Maybe I just missed something about them?
Update:
scala.mobile was removed in Scala 2.9.
I just checked the source code.
When Scala changed the name mangling of class files a few years ago and it seems people forgot to update these classes accordingly.
So my answer would be:
At least Location has no purpose, because it is not possible to get anything sensible out of it (except exceptions) and Code without Location is severely limited. It works though if you pass the class literal to Code directly:
import scala.mobile._
val c = new Code(classOf[scala.collection.mutable.StringBuilder])
c.apply[StringBuilder, String]("append")("Foo")
c.apply[String]("toString")() // returns "Foo"
c.apply[Int]("length")() // returns 3
Looks like yet-another implementation in the standard library of reflection-slightly-nicer.
The description of Location pretty much explains what that is about:
The class Location provides a create method to instantiate objects
from a network location by specifying the URL address of the jar/class file.
It might be used by remote actors. Maybe.
As for why it has this misleading name? Well, back in 2004 smart phones had really low penetration, so maybe the association wasn't all that strong.