This message was deleted.
# community-support
s
This message was deleted.
e
as https://docs.gradle.org/current/dsl/org.gradle.api.plugins.PluginAware.html says, it is preferred to use
pluginManager.apply(...)
instead of
plugin.apply(...)
✅ 1
what sort of problems are you facing? for this to work, it is expected that (non-core) plugins you are applying are also declared as runtime dependencies of your plugin
c
Basically i get classloading issues telling me that classes are not present. And when I look at the classpath i sometimes have them twice.
Let me check if pluginManager, improves this.
v
Actually it recommends to use
project.apply(...)
😄 But either way will most probably not change any problems you might have as these methods of applying do not influence class loaders.
What classloading issues you have is hard to tell without more details. If you for example have
compileOnly
dependencies on those plugins and then apply your plugin in the root project but the other plugin only in a subproject, then your plugin cannot access the plugins classes as they are on a classloader lower in the hierarchy.
c
We've been using project.getPlugins().apply() so far. I think (best guesss for now) that the classloader issues come from the newest version of the jfrog artifactory plugin (which adds compatibility for gradle 8.4 and we're still on 8.3). We downgraded and that solved the issues.
👌 1
5.1.11 -> 5.1.10
v
Yeah, that plugin is often a source of pure joy. Better just use the standard
maven-publish
if you can. 🙂
😁 1
c
Regarding the plugin loading, what's the preferred way then? Because we use
this.project.getPlugins().apply(pluginId);
and
this.project.getPluginManager().withPlugin(id, action);
Should we align this to always use the pluginmanager?
v
Read the JavaDoc of
project.getPlugins()
, that should make it clear. 🙂 If not, feel free to ask again.
(I already mentioned above which is recommended as of that JavaDoc 😉)
c
👌 1