unapplyfor javaparser, localized to just https://github.com/blast-hardcheese/guardrail/blob/b175c0c4fbe0bfd6a068cf32533f19be6a0ef505/modules/java-support/src/test/scala/tests/generators/helpers/JacksonHelpersTest.scala#L88-L92 for now
providedswitchup, I think it's more stable now. The last time I tried publishing it introduced ABI incompatibilities, after a bit of back and forth I convinced SBT to use explicitly published jars when building release artifacts, which should make everything more stable overall.
*.clientpackages. Is there a way to generate only the shared data structures -- so that we could create shared functionality for them, like validators, etc -- that would be used by both Server and Client?
definitions, but, given the same spec, they will always be the same between clients and servers
Also, if I want to have a JAR with the shared data-structures that is to be then depended upon by both Server and Client, how do I do that?
you more or less can't, at least not without some gymnastics. you could generate in
models mode (as opposed to
server) in one module, and that will give you
definitions. then in the other modules you depend on that, and generate in
server mode. but that will still generate a duplicate
definitions package, so you'll have to figure out how to delete them after generation
Hi, is there a simple fix for cases where the protocol field names contain reserved words? for example
schemas: MacroWrapper: type: object required: - macro properties: macro: $ref: "#/components/schemas/ZendeskMacro"
macro is now a reserved word; usage as an identifier is disallowed, I don't want to use the
x-scala-type extensions as a workaround because it would introduce unnecessary complexity.
If there is no fix for this yet (I'm on version 0.64) I could create an issue and for on a fix
tracingboolean, as it is better served by way of composition now that
mapRoutesexists in a number of frameworks. I would like to do this in a way that doesn't break Twilio, so if you know people are still using that feature directly, I can come up with a migration strategy.
securitySchemescomponent and referenced it globally in the security section of my openapi config. However guardrail still generates the same Handler as before. I'm using the sbt plugin for the generation. Is basic auth support only available in the cli app or am I missing something?