Package io.github.duckasteroid.agentdocs.resolve.task

Class AppliedPluginCollector

java.lang.Object
io.github.duckasteroid.agentdocs.resolve.task.AppliedPluginCollector
public final class AppliedPluginCollector extends Object
Discovers Agent-Docs-aware Gradle plugins applied via the plugins {} block.

Unlike regular dependencies, plugins applied this way aren't resolved onto a project Configuration — there's no Maven GAV to read off a resolved component. Instead, each applied Plugin's own class reveals the jar it was loaded from (via its classloader's code source), which is exactly where publish-side tooling would have stamped the Agent-Docs manifest attribute (per specification/java-conventions.md) when embedding docs — the only distribution mode supported for Gradle plugin projects.

The plugin id itself is recovered from the same jar's META-INF/gradle-plugins/*.properties descriptors (the standard mechanism java-gradle-plugin generates and Gradle itself uses to resolve id '...' to an implementation class), matched back to the applied class.

Scope is deliberately limited to binary plugins: since PluginContainer is a flat record of every applied plugin regardless of how it got applied, a convention plugin (itself a binary plugin) that internally applies other binary plugins has each of those inner plugins discovered independently, off their own jars. Precompiled script plugins (buildSrc or an included build-logic build) are out of scope: their classes resolve to a local build-output jar that was never stamped with an Agent-Docs attribute by agent-docs.publish, so they're silently skipped like any undocumented plugin — this isn't a distinct, supported code path.

A single jar can register more than one plugin id (a convention plugin jar declaring several gradlePlugin { plugins { ... } } entries); each applied class in that jar is resolved to its own id independently, and only ids that are actually applied to this project - i.e. present in plugins - are considered, never every id the jar happens to declare. Per agent-docs.publish's layout convention, each id's own bundle always lives at <declared-path>/<pluginId>/ inside the jar (see AgentDocsPublishPlugin), so the declared jar-level path is suffixed with the resolved plugin id before being handed off for extraction.

  • Method Details

    • collect

      public static List<AppliedPluginCollector.DeclaredPlugin> collect(org.gradle.api.plugins.PluginContainer plugins, org.gradle.api.logging.Logger logger)
      Collects every applied plugin whose own jar carries an Agent-Docs manifest declaration, resolving each one's plugin id along the way.

      Plugins without the attribute (essentially every core Gradle plugin, and any third-party plugin that hasn't adopted the convention) are skipped entirely — no different from a regular dependency without the attribute. A non-classpath scheme (there is no consumer-side resolution path for a maven sidecar here, since plugin jars aren't resolved as project dependencies) is skipped with a warning. A jar carrying the attribute whose plugin id can't be determined from its descriptors is skipped with an info-level log, since it's not actionable by the consumer.

      When a jar registers several plugin ids, one AppliedPluginCollector.DeclaredPlugin is returned per applied id (not per jar) — each pointing at that id's own <path>/<pluginId>/ bundle — so a jar declaring ids that weren't actually applied to this project never has docs materialized for those unused ids.

      Parameters:
      plugins - the project's applied plugins
      logger - logger for diagnostics
      Returns:
      discovered plugins with a usable classpath declaration