This message was deleted.

I think the thing is that several IDs can map to the same class, and Gradle only tracks the applied class. When using

hasPlugin

or

withPlugin

, Gradle uses an internal map of Ids to/from classes (n–1) to tell whether an applied plugin (by class) has a corresponding ID, but listing the IDs would need either making a choice as to which ID to use for a given class, or list all possible IDs. That's my understanding at least.

I think so too. There are some plugins that migrated from one plugin ID to another one, but still support usage of both afair.

I guess there's no way unless one looked into the Gradle internals

What is your actual use-case anyway?

Use-case - more or less an 'info' task which prints out all applied plugins. I was looking into

buildEnvrionment

task and I realized the core plugins aren't listed there and then started looking into alternatives..

The

buildEnvironment

task also does not show applied non-core plugins. It only shows the build script dependencies, but carries no information whether the plugins are applied or not, is which from the dependencies that can contain multiple.