Update swagger-parser to fix definition parse bug

[trane]

While parsing swagger with additionalProperties, not all definitions are
resolved in swagger-parser < 1.0.34.
(swagger-api/swagger-parser#602)
This brings us to the most recent version of swagger-parser on the 1.x
line.

Fixes: #40

[trane]

Interesting new NPE introduced from this change. Investigating.

[trane]

Looks like we aren't handling UntypedProperty within SwaggerUtil.scala#propMeta, which is being triggered by PropertyExtractorsTest

# snip
property:
  default: "what"

According to the Swagger spec (2.0) definitions (https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#definitionsObject) can have null type via the JSON schema spec: https://tools.ietf.org/html/draft-zyp-json-schema-04#section-3.5

What is the most reasonable thing to do here?

I can think of a few things:

1. Fail when type isn't present.
2. Set the type to some null or nullable-like value (not sure how we represent this in scala.meta
3. Ignore it
4. Recursively inspect the default value (which is itself required to be a JSON schema object) and use the resulting resolved type to be the type we use (though we still run into this nullable situation)

[trane]

For now, I'm failing property definitions that are untyped.

[blast-hardcheese]

@trane Thanks for the contribution and investigation! Everything looks good, save for the merge conflict -- would you please resolve this at your convenience?

[blast-hardcheese]

@trane One last time, my apologies

[trane]

@blast-hardcheese, I'm concerned about some of the behavior I'm seeing now with this code. Namely, I'm getting unhelpful errors now like:

Error: Unable to resolve type for null (null null null null)

Where before I would get

Error: No responses defined for getActivities

[blast-hardcheese]

@trane So, addressing #41 (comment):

As for HTTP, a "null" value doesn't really make sense. ?Foo= is still foo="". JSON, however, could represent literal null values. For this reason, defaulting the type-less properties to None.type might make sense, but then what does it mean to have a None.type be required. This would be a great opportunity for static parameters, where an undefined parameter always gets encoded as a None and can't be overwritten.

[trane]

This would be a great opportunity for static parameters, where an undefined parameter always gets encoded as a None and can't be overwritten.

@blast-hardcheese I'm not sure I follow what you mean by "static parameters". Are you saying that we generate a class constructor which has the None.type singleton type instead of an Option[???]?

case class MyParam(foo: String, bar: None.type)

[trane]

I did a bit more digging into what swagger-codegen did with the addition of UntypedProperty

• Untyped schemas aren't accepted swagger-api/swagger-core#2507

For all the Scala code generators, they either returned Any (Akka, Scala, etc) or Object (finch). Though, how could we create an encoder/decoder for such an arbitrary type in any meaningful way?
It appears in the case of additionalProperties and schema etc, that these all just have to be some valid json, nothing more.

Perhaps the right answer here is to resolve as a io.circe.Json?

[blast-hardcheese]

Exposing it as the underlying json library type makes sense. This would also be a stopgap for #43, although not a great one.

[trane]

Alright, I have resolved the issue with the introduction of UntypedProperty from the new swagger-parser in the best way I can think of for now. Should be good to merge if you feel good about it, too, @blast-hardcheese

[blast-hardcheese]

Does getProperties exist on UntypedProperty? UntypedProperty.java suggests it doesn't (which would also make sense, as there's no way for it to know)

[blast-hardcheese]

Additionally, something to note here is that SwaggerUtil needs to eventually be collapsed down into the different ProtocolGenerators, otherwise io.circe.Json won't be valid for other JSON libraries (json4s, support for Java, etc). Not a concern right now, but this is something that'll need to happen for #36

[trane]

yeah, I figured that the io.circe.Json was good for now given that the protocol generator stuff isn't parameterized yet. I hope it's as simple as a find/replace of io.circe.Json to ${correctProtocolGenerator} when that happens.

[blast-hardcheese]

This looks good, thanks!