This message was deleted.

a plugin can have any number of IDs

Ahh, that is interesting. Can I still query them at runtime for a given project? I'm creating a report and I'd love to be able to show which plugins have been applied. Most devs will only understand IDs though and not class names.

there is an internal

PluginRegistry

that keeps track of which plugins Gradle has seen so far, but otherwise no

It looks like

org.gradle.api.internal.plugins.PluginRegistry

is under the

.internal.

package, but how do I programatically get an instance of it? I see a constructor, but not sure how I'd get the constructor args for

public DefaultPluginRegistry(PluginInspector pluginInspector, ClassLoaderScope classLoaderScope)

To get the id -> class mapping, you can simply list all

META-INF/gradle-plugins/...properties

files and read them, then you have the id -> class mappings and can build a class -> possible ids mapping. But as @ephemient said, it could also be that a plugin has no ID but is only applied by class and you also don't know in which way the plugin was actually applied.

Okay, that should all be available on the classpath, and therefore accessible via the classloader? Interesting, okay, can 👀

Yes, it should

you have to make sure to include parent classloaders too when you do that scan

Yes, that's basically then the same as mentioned above, not having an ID at all. 🙂

there's no public way of enumerating all resources in a classloader

Yeah... all the solutions require you to walk the JAR file via inspecting it as a ZIP file. I think I'll end up doing the hard-coded list. It's only like 10 things, just wanted to make it dynamic.

Hm, I always forget I just wish there was such an api 😄

originally ClassLoader worked for applets too, loading resources from some ordinary HTTP server, which I think is why it isn't enumerable

At first pass it seems like something that should be part of Gradle... but I guess it is not because that

META-INF/gradle-plugins/my-plugin.properties

will exist, and it will refer to the fully qualified plugin class. Therefore they are explicitly able to look it up from the classloader. 🤔 So maybe there really isn't a need.

yes Gradle only ever needs resolve an ID to a class, which is easy

You could brute-force all possible plugin IDs 😄

ah yes, all ℵ₀ of them 😂

Instead... Gradle could keep a registry that could keep the id/class mapping after each was applied. It wouldn't be guaranteed to be correct until after configuration though. Since gradle is doing the lookup, it could be nice enough to expose what those were 🤔

Well, Gradle is not interested in it and most post probably noone else should either I guess. 😄