-l spring is fairly well supported in this code.

It's possible that the withXml flag is automagically set when there's a single API call definition that only uses application/xml as Content-Type in a POST or as Accept header in a GET.

@mobreza Thanks for submitting this PR! This solves for a need my team is facing. 👍
@wing328 I believe this will solve #6005 that I submitted. The approach is very similar to what I was planning on doing, except that his work is way more thorough. I will try to pull this down and test it against my use cases within the next few days.

If I may provide one bit of feedback, I would question whether it's appropriate to add a new config option withXml when there's already an option for useJaxbAnnotations. Can we reuse useJaxbAnnotations here, or is it meant to represent something entirely different? Along those lines, I'm not sure we need a flag for this at all. Is there a downside to removing the config option and always generating the XML annotations?

I cloned @mobreza's fork and built the 3870-java-application-xml branch locally. I tested it against all of my team's use cases, and everything worked correctly. I look forward to seeing this PR merged and released. Thanks!

Can we reuse useJaxbAnnotations here, or is it meant to represent something entirely different?

Very good feedback. Either is fine with me. Looking at the bigger picture, I would prefer "withXML" as it can be used in other non-java generators as well (e.g. Ruby, which has one outstanding request/feedback to support XML payload in Ruby API client)

I'm not sure we need a flag for this at all. Is there a downside to removing the config option and always generating the XML annotations?

Previously there were feedbacks to avoid unnecessary dependencies included in the auto-generated code so I prefer supporting XML via an option as it will require additional dependency "jackson-dataformat-xml" (which is not needed if the use case is JSON-only)

@wing328 we could consider folding useJaxbAnnotations into the new withXml flag.

@wing328 we could consider folding useJaxbAnnotations into the new withXml flag.

Yup, you're reading my mind. We'll do it in the 2.3.0 branch (containing breaking changes) to consolidate all other XML flags (if any) into withXML. I'll open a ticket for tracking later.

@packleader thanks for testing the changes. I'll run some tests tomorrow locally and merge th PR accordingly.

Can we reuse useJaxbAnnotations here, or is it meant to represent something entirely different?

Very good feedback. Either is fine with me. Looking at the bigger picture, I would prefer "withXML" as it can be used in other non-java generators as well (e.g. Ruby, which has one outstanding request/feedback to support XML payload in Ruby API client)

I'm fine either way as well. If we intend for withXml to be used across languages, should it moved directly under <configuration> instead of <configOptions>? I may be mistaken, but I interpret <configOptions> as language- or library-specific options. Also, we might want to update the documentation and example at swagger-codegen-maven-plugin/README.md

I'm not sure we need a flag for this at all. Is there a downside to removing the config option and always generating the XML annotations?

Previously there were feedbacks to avoid unnecessary dependencies included in the auto-generated code so I prefer supporting XML via an option as it will require additional dependency "jackson-dataformat-xml" (which is not needed if the use case is JSON-only)

That's a good point; we don't want dependency bloat. I'm sure this is a dumb question, but what is the value in using @JacksonXmlProperty instead of just @XmlElement? The latter is part of core Java, so it doesn't require any additional dependencies.

@wing328 See above about:

It's possible that the withXml flag is automagically set when there's a single API call definition that only uses application/xml as Content-Type in a POST or as Accept header in a GET.

Also let me know if you need me to rebase, squash or clean up the code in the branch.

@wing328 Also, we could aways generate the javax.xml annotations and the @Jackson* annotations. Annotations apparently don't trip the ClassNotFound exception at runtime. We could also declare the dependencies as "provided" in pom.xml.

FYI. Updated CircleCI to cover resttemplate-withXml via 898ead1

Minor enhancement/fix to gradle file: #6020 (merged into master)

@wing328 will the 2.2.3-SNAPSHOT be available on Sonatype soon?

@mobreza yes, after the build (https://travis-ci.org/swagger-api/swagger-codegen/builds/2524139110 completes, the snapshot version will be published to Sonatype.

I'm fine either way as well. If we intend for withXml to be used across languages, should it moved directly under instead of ?

@packleader at the moment, I think it should be a generator-specified option as not all generators supports XML payload via the withXML option.

Also, we might want to update the documentation and example at swagger-codegen-maven-plugin/README.md

Please feel free to submit a PR to improve the plug-in's README

Created #6084 to replace useJaxbAnnotations with withXml

Hi, XML support is only generated via Spring rest template? What if you want to use a Jersey or RestEasy client? It's too hard to add a @Provider for xml/application configuration in the generated client?

@nalmeida84 Even though the PR specifically references RestTemplate, the fix that he submitted applies to all of the libraries. I have personally tested with Jersey2 and can confirm that it works correctly.