Refactor samples

[devcrocod]

#114

Motivation and Context

• simplify the project structure
• test new features with existing samples

How Has This Been Tested?

locally

Breaking Changes

no

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[Copilot]

Pull Request Overview

This PR refactors the sample modules into the root multi-project build, removes their individual Gradle wrappers and settings, and updates their build scripts to use the central version catalog.

• Consolidate samples under the root project and remove per-sample wrapper files and settings
• Migrate sample build scripts to use the libs.versions.toml catalog and aliases
• Include new sample modules in settings.gradle.kts

Reviewed Changes

Copilot reviewed 23 out of 32 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
settings.gradle.kts	Added :samples:... modules to root project
samples/weather-stdio-server/build.gradle.kts	Updated plugins/dependencies to use version catalog; removed wrapper files
samples/kotlin-mcp-server/build.gradle.kts	Updated plugins/dependencies to use version catalog; disabled WASM optimize
samples/kotlin-mcp-client/build.gradle.kts	Updated plugins/dependencies to use version catalog and set mainClass
gradle/libs.versions.toml	Added sample library and plugin aliases

Files not reviewed (5)

• samples/kotlin-mcp-server/.idea/.gitignore: Language not supported
• samples/kotlin-mcp-server/.idea/gradle.xml: Language not supported
• samples/kotlin-mcp-server/.idea/kotlinc.xml: Language not supported
• samples/kotlin-mcp-server/.idea/misc.xml: Language not supported
• samples/kotlin-mcp-server/.idea/vcs.xml: Language not supported

Comments suppressed due to low confidence (5)

samples/weather-stdio-server/build.gradle.kts:5

• The application plugin is applied but no mainClass is configured, so the entry point won't be recognized. Please add an application { mainClass.set("your.main.ClassKt") } block with the sample's main class.

    application

samples/weather-stdio-server/build.gradle.kts:18

• Version catalog alias slf4j-nop should be referenced as libs.slf4jNop, not libs.slf4j.nop.

    implementation(libs.slf4j.nop)

samples/weather-stdio-server/build.gradle.kts:19

• Version catalog alias ktor-client-content-negotiation should be accessed as libs.ktorClientContentNegotiation, not libs.ktor.client.content.negotiation.

    implementation(libs.ktor.client.content.negotiation)

samples/weather-stdio-server/build.gradle.kts:20

• Version catalog alias ktor-serialization-kotlinx-json should be accessed as libs.ktorSerializationKotlinxJson, not libs.ktor.serialization.kotlinx.json.

    implementation(libs.ktor.serialization.kotlinx.json)

samples/kotlin-mcp-client/build.gradle.kts:17

• Version catalog alias anthropic-java-sdk should be referenced as libs.anthropicJavaSdk, not libs.anthropic.java.sdk.

    implementation(libs.anthropic.java.sdk)

[StefMa]

Instead of having one large build that includes the samples, you could also use an includeBuild aka composite build.
Just include the kotlin-mcp as an build in the samples and use it.
The benefit would be that both projects are somewhat standalone. Especially the main build.

[e5l]

This PR will make samples hard to use as standalone projects and complicate the project structure. Could you tell me why we include them into build?

[StefMa]

Could you tell me why we include them into build?

The rationale behind it is to test the current "development branch" / latest changes with the samples.
The problem is:
You have a project that points to the current development branch (main branch).
This includes the README and all the things.
You might introduce something (or APi changes etc.), but it literally can't be tested by "users" with the samples.
The samples point always to the latest stable version.
This might be confusing for people.

So I do the benfit of doing that.
However, as stated in my previous comment, maybe a better solution is to use an composite builds.
With that, the core sdk is still standalone, the samples are a bit bound to the location of the core sdk.
Otherwise, they are also standalone. You only have to point to the location of the core sdk (which is by default ../).

Does this make sense? 🤔