This message was deleted.
# plugin-development
s
This message was deleted.
v
If you don't use its classes but just apply it, even
runtimeOnly
should be fine, it just needs to be in the classpath.
k
But if you do need to use its classes,
api
?
g
If you just use its classes internally in the plugin (method implementation, etc.), just
implementation
is fine. However, if you expose its classes as part of your own plugin’s public API (e.g. an extension you expose for the user to configure your plugin has some property typed to one of those classes), then you probably need to declare it
api
☝️ 1
k
So, no
api
necessary if I just register an instance of one of its task types in my plugin, and there is no intent that the user applying my plugin would perform further configuration on it?
👍 1
👍🏻 1
t
When choosing between
api
and
implementation
, the question is: if another project has a dependency (
api
or
implementation
) on this project, does it need to have that (now transitive) dependency in its compilation classpath or would having it only at runtime be enough?
Note that using a plugin is not having "a dependency (
api
or
implementation
) on this project", so this would only apply to another plugin depending on yours.
g
If you’re not comfortable with classpaths, compilation vs. runtime, etc. @tony explains it very well in this series: https://dev.to/autonomousapps/a-crash-course-in-classpaths-run-21go
👀 1