Provide a JAX-RS 2.0 client template with minimal or zero dependencies.

[keithchong]

There are currently Jersey 2 and Jersey 1.18 JAX-RS clients with/without JSON Jackson processing,
These have additional dependencies on Jackson annotations, base 64 encoding (migbase64), joda-time, etc.

There should be a template that should use strictly JAX-RS 2.0 Client APIs, (no Jersey dependencies) and have minimal (or zero) dependencies on 'third' party jars.

[wing328]

@keithchong thanks for the feedback. Is that something you've cycle to contribute?

[keithchong]

Yes, I will contribute.

[wing328]

@keithchong thanks. Here is the guideline for contributing:

https://github.com/swagger-api/swagger-codegen/blob/master/CONTRIBUTING.md

[jfiala]

version: 2.1.5
language: Java

template file: swagger-codegen/src/main/resources/Java/auth/HttpBasicAuth.mustache

Related to #2153

The reference to com.migcomponents.migbase64.Base64 in HttpBasicAuth.mustache could easily be replaced by the already present com.sun.jersey.core.util.Base64:

// old: import com.migcomponents.migbase64.Base64;
import com.sun.jersey.core.util.Base64;
// old: headerParams.put("Authorization", "Basic " + Base64.encodeToString(str.getBytes("UTF-8"), false));
headerParams.put("Authorization", "Basic " + new String(Base64.encode(str.getBytes("UTF-8")), "UTF-8"));

Then the dependency to com.brsanthu:migbase64 in the generated client pom.xml could be removed:

<!-- Base64 encoding that works in both JVM and Android -->
    <dependency>
      <groupId>com.brsanthu</groupId>
      <artifactId>migbase64</artifactId>
      <version>2.2</version>
    </dependency>

[arthurdm]

To be consistent with (#3080), this new client generation code should use "-l java-spec".

[arthurdm]

I just realized that client-gen uses config options for different libraries instead of new languages. in this case then, it should be a new library under -l java. Would be nice if the client-gen and server-gen were consistent, but ah well, something for the future.

[wing328]

@arthurdm thanks for the feedback. We definitely want to keep things consistent and kudos to @cbornet who has already started doing that.

If you want to lend a helping hand, here is a list of tasks you can help out:

https://github.com/swagger-api/swagger-codegen/issues?q=is%3Aopen+is%3Aissue+label%3A%22Client%3A+Java%22+label%3A%22Need+community+contribution%22

[arthurdm]

thx @wing328

@cbornet - I noticed that the Online Swagger Editor only pulls in languages, and provides no way for specifying client nor server generation options, since it's calling http://generator.swagger.io/#!/clients/clientOptions and http://generator.swagger.io/#!/servers/serverOptions, which only give the top-level client/server languages.

Therefore it seems a good strategy for consolidating how servers and clients are generated would be to follow the concept that the server-gen is using, which is to introduce new languages (-l) when the client-gen libraries differ - although I agree the implementation under the covers can be restructured to avoid code duplication.

That would fit well with the current way that the online editor pulls in things, unless there's also work underway to be able to specify sub-libraries/options for a server/client generation in the online editor?

[cbornet]

Well, this is more an issue with the swagger-editor. See swagger-api/swagger-editor#713

[arthurdm]

I agree that we need to look into the swagger editor at some point on how to configure extra options. I do still feel though, that we should make the Java client and server generation more consistent than it is now. I see that for typescript we have 4 types of clients, all using different -l instead of options, and 2 -l's for javascript, so why are we treating Java clients as libraries?

I think if we made the current Java client libraries into corresponding languages (with proper hierarchy chains and extending from common base classes), then we would:

• align it with the server-side gen
• align it with other client-side gens (like javascript and typescript)
• work out-of-the-box with the current editor

Thoughts?

[wing328]

@arthurdm it depends on the situation/use cases when it comes to using --library/-l or a new generator for another language/framework.

For typescript, ideally we want to use --library but the contributors who created the new generators didn't have time for that. As you can see, when we fix certain issues in typescript, we've to do it for all 4 typescript generators (and I need to make sure the same fix is applied to all 4 generators every time), which is the additional overhead to maintain multiple generators for the same language.

If we use --library, there's also an overhead when it comes to making changes since the same generator is shared by different libraries, we need to ensure the change won't break any other libraries. This makes contributions from the community a little bit more challenging as most of the time the contributors only test the change they made but not other libraries that might also be impacted by the change.

For option to customize the SDKs generated by editor.swagger.io (which actually uses generator.swagger.io), please refer to https://github.com/swagger-api/swagger-codegen#online-generators.