getsentry / getsentry/sentry-java
Separate sample projects from test infrastructure (converted to project)
- Langage dominant
- Kotlin
- Étoiles
- 1.4k
- Forks
- 478
- Merge moyen
- 2 j 23 h
- PR mergées (30 j)
- 67
Description
This issue has been converted to a project [Separate sample projects from test infrastructure]()
---
Currently our samples double as integration tests, which causes buildscript classpath bleed between the main build and the sample projects. This creates two categories of problems:
**Isolation failures observed**
* A test matrix leg targeting a specific KGP version was silently resolved to a higher version because another build dependency pulled it in transitively
* Sample dependency constraints (e.g. an older Spring Boot requiring a pinned KGP version) block upgrades to the rest of the build
**Goals**
* Samples should use only published Maven Central coordinates so customers can copy them verbatim — no project references, no snapshots
* Integration tests should live in a separate Gradle project (or composite build) with an isolated buildscript classpath, publishing to a build-local directory for resolution
* Changes to the main build graph should not be able to silently alter what the samples or integration tests resolve
**Proposed direction**
* Extract sample apps into standalone Gradle projects (or an isolated composite build) that declare no `project(...)` dependencies
* Run integration/system tests against those standalone projects, resolving SDK artifacts from a build-local Maven directory (see [JAVA-625]())
* CI wires the publish-to-local-dir step before the sample test step, keeping full per-PR coverage
**Out of scope**
* The build-local dir plumbing itself (tracked in [JAVA-625]())
* Publishing samples to any external registry
--
[View Junior Session in Sentry]()
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Work is tracked in the linked Linear project rather than this issue. Start by mapping the current sample Gradle projects, integration/system tests, and CI wiring, then review JAVA-625 for the build-local resolution dependency; done means samples use published coordinates while isolated integration tests retain full per-PR coverage.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- java, kotlin, spring-boot
- Domaine
- build-system, ci-cd, testing
- Type d'issue
- Refactorisation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 15/100