Worth noting that these API surface tests are not in a great state; they test everything on the class path rather than just true dependencies. I don't know that they still ensure the desired property; they certainly reject things that they need not. From your description, it sounds like in your case they have worked as intended.
Kenn On Tue, Oct 2, 2018 at 1:37 PM Andrew Pilloud <[email protected]> wrote: > Hi Ken, > > My understanding is that this test is intended to prevent other packages > from appearing on the public API surface of the Beam package. For example, > guava can't appear on the Beam public API. This is to enable users to > depend on different versions of these packages then what Beam depends on. > > See > https://issues.apache.org/jira/browse/BEAM-878https://issues.apache.org/jira/browse/BEAM-878 > > We might be able to provide more guidance if you open a Beam PR with your > changes so we can see the diff and test failures. > > Andrew > > On Tue, Oct 2, 2018 at 1:02 PM Kenneth Jung <[email protected]> wrote: > >> Hi folks, >> >> I'm working on adding support for a new API to the google-cloud-platform >> SDK, and some of my changes have caused the API surface test >> <https://github.com/apache/beam/blob/master/sdks/java/io/google-cloud-platform/src/test/java/org/apache/beam/sdk/io/gcp/GcpApiSurfaceTest.java> >> to start failing. However, it's not totally clear to me what the purpose of >> this test is -- it doesn't fail when new build-time dependencies are added, >> but only when new types appear on the public API surface of the package. >> What is the purpose of this test? Is it to prevent accidental additions of >> new dependencies, or to make sure that the shadow configuration stays in >> sync with the content of the package, or is there something else I'm not >> thinking of? This will affect how I go about addressing the failures. >> >> Thanks >> Ken >> >
