Use the shadow plugin to shade Jetty #225
Conversation
This allows clients that have not migrated onto Jetty 12 yet to use Tempest after the AWS DynamoDB Local upgrade Changes: * Upgrade gradle to v8.13 (required for shadow plugin) * Add the `tempest-dynamodb-local` subproject to manage the AWS DynamoDB Local dependency * Manually manage the transitive dependencies of AWS DynamoDB Local to prevent unexpected modules from being shaded * Use the shadow plugin to shade and relocate Kotlin Stdlib, Jetty, Jackson, and AWS DynamoDB Local
* Bump gradle-maven-publish-plugin to v0.28.0 * Hoist `dokkaGfm` outout directory setting outside of source sets loops to fix task dependencies in Gradle * Use a custom POM for `tempest-dynamodb-local` so that it use the shadow classpath when generating the runtime dependencies * Override the archive classifier on the unshaded jar to disambiguate the task output from the shadow jar
| } | ||
|
|
||
| dependencies { | ||
| // Ignore transtive dependencies and insyead manage explicitly. |
| } | ||
|
|
||
| // Relocate packages to avoid conflicts. | ||
| relocate("com.amazon.dynamodb.grammar", "shaded.com.amazon.dynamodb.grammar") |
There was a problem hiding this comment.
nit: it might be better to use a more unique prefix, like tempest.shaded rather than shaded. In case somebody else is also shading these classes and some poor downstream consumer gets both copies
There was a problem hiding this comment.
Good call, added a project-specific prefix to the package name.
| // Add a new dependencies node with shadow configuration. | ||
| val dependenciesNode = root.appendNode("dependencies") | ||
|
|
||
| // Add all shadow dependencies to the POM. |
There was a problem hiding this comment.
The net effect here is to remove the dependencies that were shaded, right? Kinda surprised this needs to be done explicitly but I don't have much experience with the intersection of shadow and publication
There was a problem hiding this comment.
Yeah, this surprised me as well. What's happening is that the publication is using the runtime classpath, which is not the same as the shadow classpath of the shadow jar. If you publish via the shadow plugin, it can handle this for you, but I didn't want to change the publication mechanism.
There was a problem hiding this comment.
There was a problem hiding this comment.
I didn't want to switch which plugin was used to publish to maven, but if we're okay with doing this via the shadow plugin and it's easier then let's do it.
This allows clients that have not migrated onto Jetty 12 yet to use Tempest after the AWS DynamoDB Local upgrade
Changes:
tempest-dynamodb-localsubproject to manage the AWS DynamoDB Local dependency