getsentry / getsentry/sentry-java

Use build-local dir instead of project deps in samples

オープン
#5,711 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る
Improvement Java Platform: Java
主要言語
Kotlin
スター
1.4k
フォーク
478
平均マージ
2日 23時間
マージ済み PR(30日)
67

説明

Our Spring Boot + OTel samples currently use project dependencies (e.g. `project(":sentry-opentelemetry:sentry-opentelemetry-bom")`), which:

- Pollutes the buildscript classpath, undermining test isolation
- Makes the samples uncopyable by customers (who won't have project references)
- Masks real compatibility issues (e.g. OTel + Spring Boot version conflicts hidden by the BOM being pulled via project ref rather than a real artifact)

**Proposed change**

Publish SDK artifacts to a build-local Maven directory during CI and configure the samples to resolve from that directory. This preserves per-PR test coverage without the classpath isolation problems of `mavenLocal` (which has shared global state) and without requiring publishing to Maven Central.

**Scope**

- Set up a build-local publish step that outputs to a local directory (e.g. `build/local-repo`)
- Update sample `build.gradle.kts` files to add that local dir as a repository
- Use published coordinates (e.g. `io.sentry:sentry-opentelemetry-bom`) instead of project references in `dependencyManagement`
- Keep samples using released/stable version strings so customers can copy them as-is

**Out of scope**

- Moving samples to Maven Central publishing
- Fully separating samples from test infrastructure (tracked separately)

--

[View Junior Session in Sentry](https://sentry.sentry.io/explore/conversations/slack%3AC089VFRB8N9%3A1783054068.421249/?project=4510944073809921)

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

Start by reading the sample build.gradle.kts files and the CI build configuration that publishes SDK artifacts. Trace the current project dependency and dependencyManagement setup, then verify that samples resolve published coordinates from the build-local directory with stable version strings and that the CI sample tests pass.

索引モデルが issue の本文から書いたものです。

評価

技術スタック
kotlin, spring-boot
領域
build-system, ci-cd
issue の種類
リファクタリング
難易度
4/5
見積もり時間
3〜5日
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
52/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。