Detecting internal/incubating API usage in custom plugins

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Detecting internal/incubating API usage in custom plugins

Lóránt Pintér-2
Hi,

Is there a way to detect during the build of a plugin if it uses any internal/incubating Gradle APIs (any maybe fail the build if that’s the case)?

I’m thinking about something like this:

    $ gradle checkGradleApis
    :checkGradleApis
    in com.example.SomeClass(SomeClass.java:14): Incubating API used
    in com.example.SomeClass(SomeClass.java:18): Internal API used
    
    BUILD FAILED

This would be very useful to check plugins we would like to adopt in our builds, so we could tell beforehand if they are expected to break when we have to upgrade to a new minor Gradle version.

Thanks,
Lorant

Lóránt
Reply | Threaded
Open this post in threaded view
|

Re: Detecting internal/incubating API usage in custom plugins

Luke Daley-2


On 7 September 2014 at 8:32:31 pm, Lóránt Pintér ([hidden email]) wrote:

Hi,

Is there a way to detect during the build of a plugin if it uses any internal/incubating Gradle APIs (any maybe fail the build if that’s the case)?

There isn’t.



I’m thinking about something like this:

    $ gradle checkGradleApis
    :checkGradleApis
    in com.example.SomeClass(SomeClass.java:14): Incubating API used
    in com.example.SomeClass(SomeClass.java:18): Internal API used
    
    BUILD FAILED

This would be very useful to check plugins we would like to adopt in our builds, so we could tell beforehand if they are expected to break when we have to upgrade to a new minor Gradle version.

This would only be possible for 100% Java code, and even then I’m not sure we’d be able to reliably do this (i.e. detect _all_ usages).

We could do runtime checks like we do for deprecation. This is less useful though as it requires the code path being hit and requires stack traces in order to be able to infer the call site. Given that the majority of users use the dynamic APIs, a runtime solution is probably the only option.