WIP: Move to Dropwizard 2.0 series

[sdreynolds]

Why:

1.3 branch was last released in 2020-12 making it pretty stale. Moving off of this branch keeps us with the releases.

How:

This should remove all references to dropwizard 1.3.X releases and should add the specific dependencies required for this project. Specifically, with Dropwizard 2.X, Guardrail needs to include

1. hibernate-core
2. hibernate-validator

as they are no longer transitively pulled into the project via Dropwizard dependencies.

Need Help:

I don't understand how the classpath for the tests is constructed. This results in the classpath missing the hibernate dependencies during test runs.

[kelnos]

There's more to it that this, IIRC, as I believe we generate code that makes use of Jersey classes that have incompatible changes between the versions in use between DW 1.x and 2.x. Unfortunately this means that we'll need to have separate generators (which will of course share most of the code) for 1.x and 2.x, in order to keep the ability to generate code for users who are still on 1.x, as well as support folks who want to use 2.x.

[blast-hardcheese]

@sdreynolds The easiest way I've found to make big sweeping changes like this is to

• take a project that already uses guardrail,
• do a clean compile,
• then move the generated sources into the main source tree
• and disable the plugin.

That will let you explore with updating whatever dependencies or adding new features or whatever.

Once you have an idea of what to change, you can then iterate on your patches until the tests pass.

[blast-hardcheese]

@kelnos Also, if you release an internal version of https://github.com/guardrail-dev/guardrail/tree/master/modules/codegen/src/main/scala/dev/guardrail/generators, combined with a dependency with the internal frameworks at Twilio, that should be sufficient to use the main guardrail build tooling plugin instead of the cumbersome release chain we had before. That might help with this effort.

(Also really understanding the value of ServiceLoader and the new ModuleFinder stuff. Combined with the provided stuff I've done, this would make swapping in Twilio modules more stable, instead of relying on dependencies alone)

[blast-hardcheese]

Alrighty, I've been sorta hands-off on this because I really don't know anything about it, but I was able to stumble through at least enough of the deprecation notes to get it to attempt the tests.

I had no idea what whatever Unwrapping is, so I commented it out. Presumably we'll end up with runtime errors, but it gets us closer to iterating

[martijnhoekstra]

A problem here is that dropwizard-scala is discontinued and has no dropwizard 2.x support