getsentry / getsentry/sentry-java
Separate sample projects from test infrastructure (converted to project)
- Linguagem predominante
- Kotlin
- Estrelas
- 1.4k
- Forks
- 478
- Merge médio
- 3d 4h
- PRs com merge (30d)
- 72
Descrição
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]()
Guia de contribuição
Direção de pesquisa
O trabalho é acompanhado no projeto Linear vinculado, e não nesta issue. Comece mapeando os projetos Gradle de exemplo atuais, os testes de integração/sistema e a configuração de CI; em seguida, revise JAVA-625 quanto à dependência de resolução local do build. O trabalho estará concluído quando os exemplos usarem coordenadas publicadas, enquanto os testes de integração isolados mantiverem a cobertura completa por PR.
Escrita pelo modelo de indexação a partir do texto da issue.
Avaliação
- Stack de tecnologia
- java, kotlin, spring-boot
- Domínio
- build-system, ci-cd, testing
- Tipo de issue
- Refatoração
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Status de atividade
- Estagnada
- Clareza
- Razoavelmente clara
- Facilidade para iniciantes
- 15/100