SDK should have runtime hamcrest dependency or should bundle it
- Dominant language
- Java
- Stars
- 8.7k
- Forks
- 4.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 196
Description
`TestOptions`, `SerializableMatchers`, and `PAssert` have compile-time dependencies on hamcrest. We scope it `provided` to avoid having it on the classpath at runtime.
This has lots of pain points, but one that recently bit the Spark runner is that when `TestOptions` or any subinterface is registered, we gain a runtime dependency on Hamcest. So users of the Spark runner all had to provide it, even outside of testing.
We should just simplify this to either not have this dependency (perhaps via some hacking to make shading possibly) or declare the dependency.
Imported from Jira [BEAM-2237](https://issues.apache.org/jira/browse/BEAM-2237). Original Jira may contain additional context.
Reported by: kenn.
Contributor guide
Research direction
Start by locating TestOptions, SerializableMatchers, and PAssert, then inspect the Java SDK dependency declaration that scopes Hamcrest as provided. Reproduce the Spark runner failure when TestOptions or a subinterface is registered without Hamcrest. Done means the chosen dependency or shading approach removes the runtime failure for users who are not testing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100