getsentry / getsentry/sentry-java

Use build-local dir instead of project deps in samples

Open
#5,711 2 comments 0 reactions 0 assignees View on GitHub
Improvement Java Platform: Java
Dominant language
Kotlin
Stars
1.4k
Forks
478
Avg merge
2d 23h
Merged PRs (30d)
67

Description

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)

Contributor guide

Open the contributing guide

Research direction

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.

Written by the indexing model from the issue text.

Assessment

Tech stack
kotlin, spring-boot
Domain
build-system, ci-cd
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.