jshowalter
Occasional Contributor
Joined 5 years ago
User Profile
User Widgets
Contributions
Re: Formatting a few years ago was better than with current Swagger
For some reason it's generating a second version of most files (both PHP and Java), suffixed with a "2" (it skips files with "Parameters" in their names). Then it references the "2"s instead of the ones without the "2"s. But the ones without the "2"s have additional data, which explains why we see missing data. Why is it creating "2"s at all?684Views0likes1CommentFormatting a few years ago was better than with current Swagger
We're migrating our code generators off a fork of Swagger from a few years ago onto the latest Swagger. Overall things have gone surprisingly well, but the formatting in the generated output has changed. For example, this: - Package version: 1.0.0 - Build package: com.foo.bar now looks like this: - Package version: 1.0.0- Build package: com.foo.bar and this: "version": "1.0.0", "description": "", now looks like this: "version": "1.0.0", "description": "", and this: * Foo API * * APIs for foo stream * * OpenAPI spec version: v3.1.0 now looks like this: * Foo API* * APIs for foo stream* * OpenAPI spec version: v3.1.0 and this: $responseBody = $response->getBody(); now looks like this: $responseBody = $response->getBody(); and this: $report .= ' OpenAPI Spec Version: v3.1.0' . PHP_EOL; $report .= ' SDK Package Version: 1.0.0' . PHP_EOL; $report .= ' Temp Folder Path: ' . self::getDefaultConfiguration()->getTempFolderPath() . PHP_EOL; now looks like this: $report .= ' OpenAPI Spec Version: v3.1.0' . PHP_EOL; $report .= ' SDK Package Version: 1.0.0' . PHP_EOL; $report .= ' Temp Folder Path: ' . self::getDefaultConfiguration()->getTempFolderPath() . PHP_EOL; and this: { $this->container['app'] = isset($data['app']) ? $data['app'] : null; $this->container['description'] = isset($data['description']) ? $data['description'] : null; $this->container['template'] = isset($data['template']) ? $data['template'] : null; $this->container['placeholders'] = isset($data['placeholders']) ? $data['placeholders'] : null; $this->container['is_enabled'] = isset($data['is_enabled']) ? $data['is_enabled'] : true; } now looks like this: { $this->container['app'] = isset($data['app']) ? $data['app'] : null; $this->container['description'] = isset($data['description']) ? $data['description'] : null; $this->container['template'] = isset($data['template']) ? $data['template'] : null; $this->container['placeholders'] = isset($data['placeholders']) ? $data['placeholders'] : null; $this->container['is_enabled'] = isset($data['is_enabled']) ? $data['is_enabled'] : true; } and this: public function listInvalidProperties() { $invalidProperties = []; if ($this->container['app'] === null) { $invalidProperties[] = "'app' can't be null"; } if ($this->container['description'] === null) { $invalidProperties[] = "'description' can't be null"; } if ($this->container['template'] === null) { $invalidProperties[] = "'template' can't be null"; } if ($this->container['placeholders'] === null) { $invalidProperties[] = "'placeholders' can't be null"; } return $invalidProperties; } now looks like this: public function listInvalidProperties() { $invalidProperties = []; if ($this->container['app'] === null) { $invalidProperties[] = "'app' can't be null"; } if ($this->container['description'] === null) { $invalidProperties[] = "'description' can't be null"; } if ($this->container['template'] === null) { $invalidProperties[] = "'template' can't be null"; } if ($this->container['placeholders'] === null) { $invalidProperties[] = "'placeholders' can't be null"; } return $invalidProperties; } and this: protected static $attributeMap = [ 'app' => 'app', 'description' => 'description', 'template' => 'template', 'placeholders' => 'placeholders', 'is_enabled' => 'isEnabled' ]; now looks like this: protected static $attributeMap = [ 'app' => 'app', 'description' => 'description', 'template' => 'template', 'placeholders' => 'placeholders', 'is_enabled' => 'isEnabled' ]; and so forth. We don't do any formatting or postprocessing. These formatting changes are definitely coming from the off-the-shelf Swagger jars. Is there some linefeed setting that was added to Swagger after we forked that we need to set somewhere in the properties/configuration? The formatting changes only in some places. There are many places where the formatting is exactly what we'd expect, but sprinkled with bad formatting in seemingly random places (but repeatably the same places--it's the same every time we run the code generator). There doesn't seem to be a pattern. Most puzzling, it also is appending the numeral "2". For example, this: * @return \Swagger\Client\Foo\Model\Reference|null turns into this: @return \Swagger\Client\Foo\Model\Reference2|null and this: protected static $swaggerTypes = [ 'bar' => '\Swagger\Client\Bar\Model\Plane', 'baz' => '\Swagger\Client\Baz\Model\Train' ]; turns into this: 'bar' => '\Swagger\Client\Bar\Model\Plane2', 'baz' => '\Swagger\Client\Baz\Model\Train2' ]; We have nothing in our templates with the "2"s. It's definitely coming from Swagger. We have more than 900,000 lines of diffs between our old and new code, which makes it basically impossible to determine if we have introduced any semantic changes!697Views0likes2CommentsAre readonly and writeonly implemented for Java code generation?
Last year, we added readOnly in api.json for a service, invoked the CLI via io.swagger.codegen.SwaggerCodegen, and it didn't work. We wound up having to fork the code and make changes to OpenAPIDeserializer, ModelDeserializer, CodegenProperty, and DefaultCodegen to get it to work, which seemed weird. We'd love to be able to unfork that code.Solved1.2KViews0likes1Comment