Just adding a bit to what Kenn said, this is the JIRA that covers the
classpath issue (which seem not to affect you at least)
https://issues.apache.org/jira/browse/BEAM-3748
Note also that the classpath based resolution is not future
compatible, I saw it broke when working on the migration to Java 11
(long time ago) so we probably need to replace/improve it.
On Wed, Oct 3, 2018 at 5:56 AM Kenneth Knowles <[email protected]> wrote:
>
> 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 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
