Add a Gradle Plugin for codegen#1235
Conversation
adwsingh
force-pushed
the
adwsingh/gradle-plugin
branch
from
b19eccd to
7687f8a
Compare
|
|
||
| @Override | ||
| public void apply(Project project) { | ||
| project.getPlugins().apply(JavaLibraryPlugin.class); |
There was a problem hiding this comment.
In case of a server I believe this should be just java right?
| Set<String> resolved = modes.get(); | ||
| addIfAbsent(deps, project.getDependencies(), "codegen-plugin", version); | ||
| if (resolved.contains("client")) { | ||
| addIfAbsent(deps, project.getDependencies(), "client-core", version); |
There was a problem hiding this comment.
does it need to be here? 🤔
There was a problem hiding this comment.
codegen-plugin only has client-core as compileOnly, and client mode validates Client is present at runtime via Class.forName, so it does need to be present on the smithyBuild classpath. The dependency in the other block is for compiling/consuming the generated source.
There was a problem hiding this comment.
Yeah this makes sense, but isn't it that for the clients client-core must be an api-level dependency as the codegen result depends on it and exposes some part of it? smithyBuild inherits implementation that inherits api iirc.
| addIfAbsent(deps, project.getDependencies(), "client-core", version); | ||
| } | ||
| if (resolved.contains("server")) { | ||
| addIfAbsent(deps, project.getDependencies(), "server-api", version); |
There was a problem hiding this comment.
shouldn't this be part of implementation instead? 🤔
There was a problem hiding this comment.
Same rationale as the client-core comment
adwsingh
force-pushed
the
adwsingh/gradle-plugin
branch
from
7687f8a to
cc09ab3
Compare
adwsingh
force-pushed
the
adwsingh/gradle-plugin
branch
from
c2c28b7 to
361bdd3
Compare
adwsingh
force-pushed
the
adwsingh/gradle-plugin
branch
from
361bdd3 to
4c661c2
Compare
3 participants
What behavior changes?
Adds a Gradle plugin (
software.amazon.smithy.java.gradle.smithy-java) that replaces manualsmithy-base+afterEvaluateboilerplate with a single plugin application that auto-wires source sets, dependencies, and task ordering.Why is this change needed?
Every customer project currently duplicates ~30 lines of Gradle plumbing to wire generated code. This plugin makes the zero-config path a one-liner and provides an explicit DSL (
modes,generatedPluginOutputs) for customization.How was this validated?
./gradlew :mcp:mcp-schemas:sourcesJar :mcp:mcp-schemas:jar --rerun-tasks --configuration-cachepasses with correct service files in all artifacts. Configuration cache reuse confirmed on subsequent runs.What should reviewers focus on?
SmithyJavaPlugin.java(dependency wiring viaValueSource, service-file merge witheachFilesource-path filtering) andSmithyBuildModesValueSource.java(configuration cache tracked file read).Additional Links
N/A
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.