Add Gradle tasks

[slifty]

This PR adds Gradle tasks for bootstrapping new language modules AND for actually utilizing those language modules to generate an SDK.

Depends on #3 (and includes commits from it).

[slifty]

@bickelj pointed out in zulip that it would be worth trying to use an existing gradle plugin for code gen. I had initially explored the gradle plugin that the swagger-codegen project links to and shifted away because it was not the path of least resistance in the moment (I was trying to learn too many things at once and it was an extra layer of abstraction).

Now that I better understand how custom code modules work / get used to generate code it's worth taking another look!

I'm not sure the plugin supports what we need for the custom module generation / building, and so I bet we're going to need to use the cli jar either way for those specific tasks.

[slifty]

OK! I could be wrong here, but it looks like what we're doing is distinct enough from what the plugin supports that we're better off not using it.

As far as I can tell the plugin does NOT support the workflow for creating and packaging custom class modules as documented by the swagger-codegen repository. This functionality is bit core to what we're trying to accomplish / enable with first few tasks created by this PR.

The plugin does, in theory, support the use of custom code modules but there are no clear examples / I don't quite understand how one would use them.

For now, at least, I think it's not going to meet our needs.

[bickelj]

@slifty In that case, I think as a "get it working" step, calling java in the build step might be OK, but since either Groovy or Kotlin are running in a JVM during build time it would be better to call the swagger codegen library more directly. I think the docs on external libraries used by the build script is something like how this could be done.

Gradle is great once it's all working but it is a nightmare to figure out how to get it just right and gradley enough!

[bickelj]

@slifty Looking over https://github.com/int128/gradle-swagger-generator-plugin I would be surprised if it doesn't help meet our needs, but I agree that it is not sufficient by itself. It would probably be something like:

1. Use the plugin to generate source code,
2. use a custom copy task to copy code from that generated dir to a place gradle expects to find code to build Java Libraries - yes the Maven dir layout,
3. use the out-of-the-box Gradle Java Library Plugin to build the SDK jar,
4. use another plugin to publish the jar.

Something along those lines. And maybe with some options in the plugin, it could generate the source code directly into the right place such that (2) can be skipped.

[slifty]

@bickelj Sanity check since I think we might be speaking about different things (might be easiest to talk through than type through, because we might NOT be speaking about different things!)

The process I'm talking about is the steps that happen before what you're describing:

1. use the swagger-codegen-cli to generate a bootstrapped template module (this happens one time EVER for each language we want to generate an SDK for -- it is how we create new custom templates. For phase 2 I expect it to only happen once since we're planning to only create a typescript sdk / only need to create templates for one language). This is the thing that the plugin doesn't touch at all. This step is covered by the createLanguageModule task in the current PR.

2. Develop the custom template (e.g. #2) -- this involves populating the bootstrap-generated module definition and implementing the mustache templates. This represents an ongoing developer task since this work is checked into the repository and the templates are going to be updated / maintained over time.

3. Package our custom template into jars (this is the mvn build step). This will happen every time we want to update our templates. It's captured by the packageLanguageModule task.

These steps result in a jar that can be loaded by swagger-codegen to expand the list of languages that it knows how to generate code for.

From this point I bet the plugin could be useful (though I don't yet know how to tell the plugin to load that custom jar. For the CLI it's just a matter of adding the jar to the class path and then it magically knows how to load it.

[slifty]

Coming back to all this. My plan is going to be to have gradle ONLY be responsible for downloading the appropriate jar.

I'm going to propose we lean on npm for invoking the builds, since we already use node / npm for the project at large. We could use a bash script directly but by just using npm I don't need to think as much about OS interoperability.

[slifty]

I'm closing this PR and I opened an issue (#5) in order to more directly implement this new plan. I don't want to lose this branch until that's resolved in case we decide it is a useful path.

[slifty]

Closing this officially now that #6 is opened