gradle-revapi
gradle-revapi copied to clipboard
Allow whitelisting/enumeration of specific classes as API surface
What happened?
We develop a number of Gradle plugins, where we define the API to be the plugin id and Gradle extension(s). Implementation code wires the extension properties to Gradle tasks, and we consider the extensions to be the consumer-facing API. (IOW we follow guidance here: https://docs.gradle.org/current/userguide/custom_plugins.html#sec:mapping_extension_properties_to_task_properties, Capturing user input from the build script through an extension and mapping it to input/output properties of a custom task is a useful pattern. The build script author interacts only with the DSL defined by the extension. The imperative logic is hidden in the plugin implementation.
)
We find that when we modify how the tasks work or how they wire together, we often get revapi flags that need to be accepted and documented - however we don't consider these API changes, and want our consumers focusing on changes in the extension as how they should interact with our product.
In a more conventional Java product we might go with separate *-api
and *-impl
projects and only apply revapi to the former; however with a small Gradle-plugin project with a handful of classes, splitting out projects seems like needless complication of the repo itself in order to take advantage of the revapi tool.
What did you want to happen?
It would be nice if the revapi extension offered a class whitelist option or enumeration mode where developers could designate specific classes in a project to be the API surfaces, with revapi flagging and annotating changes to those classes, with other classes judged implementation details that don't require changes to be logged in the revapi.yml.