palantir
Check that my api depencenies include all types exposed in the api
What happened?
It's possible to publish an api that's not implementable by consumers by not bringing in transitive dependencies that you depend on at compile scope. For instance if I have an interface that exposes guava's ListenableFuture but guava is only an implementation for my package. The api will compile perfectly fine in my project but anyone consuming published package will see compile error
What did you want to happen?
Revapi should fail with a message indicating some of the classes in the api are not compile dependencies
Revapi has this kind of check - https://revapi.org/modules/revapi-java/index.html#external_class_exposed_in_api . Would you be able to share more info about your configuration to see why is this not being flagged? It is only by default classified as potentially breaking.
@metlos At the moment we explicitly ignore externalClassExposedInAPI as internally some of our APIs do use types from external dependencies. While this is non-ideal, it's not something easily changed and stopped us from rolling out revapi widely, so we disabled it.
I think @robert3005's problem is different from ensuring external classes are not exposed in APIs (we actually want to support them being exposed). He wants to make sure that if you've used external types in your API, it is an api rather than implementation dependency in Gradle, so when people depend on your jar they will automatically pick up the external dependency as well. Currently gradle-revapi is setup to inspect the "runtime" classpath, rather than the "api" classpath, so this doesn't get picked up.
